Add DependsOnDatabaseInitializationDetector so engines wait for database initializers

[nikhiln64]

Implements #4213, following the approach @filiphr outlined there ("You can go ahead and create a PR for this").

What: a FlowableDependsOnDatabaseInitializationDetector extending Spring Boot's AbstractBeansOfTypeDependsOnDatabaseInitializationDetector for org.flowable.common.engine.api.Engine (covering process/cmmn/dmn/app/idm engines through the shared interface, no bean names), registered under the DependsOnDatabaseInitializationDetector SPI in spring.factories. Spring Boot's DatabaseInitializationDependencyConfigurer then orders every engine bean after Flyway/Liquibase/spring.sql.init initializers.

Opt-out: flowable.depends-on-database-initialization-detection=false (default true), mirroring the JPA detector's opt-out pattern per the issue discussion; documented in additional-spring-configuration-metadata.json.

Testing: FlowableDependsOnDatabaseInitializationDetectorTest uses ApplicationContextRunner with spring.sql.init and asserts the processEngine bean definition gains dependsOn on dataSourceScriptDatabaseInitializer, plus the opt-out case. Verified the assertion goes red when the spring.factories registration is removed. I can add a Flyway-based sample under flowable-spring-boot-samples as a follow-up if you'd prefer that shape of test as well.

• Unit tests added
• Documentation: property registered in configuration metadata

Developed with AI assistance (Claude Code), reviewed and driven by a human.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[filiphr]

Thanks @nikhiln64. This looks good, I've only left some comments for the tests

[nikhiln64]

@filiphr just a gentle nudge on this one. All the review comments were addressed back on July 15 and the branch is current with main, so whenever you get a moment for another look I believe it is ready.

[filiphr]

Thanks @nikhiln64. I've let the CI run one more time and I'll merge it afterwards

[nikhiln64]

Quick note on the JDK 25 run since you mentioned merging after CI. The only failure is KafkaChannelDefinitionProcessorTest.fixedBackOffMultiTopicRetry in the event registry module, which errored with Topic(s) [fixed-backoff-multi-retry-topic-0] is/are not present and missingTopicsFatal is true, so the Kafka topic was not created in time on the CI broker. The JDK 17 and JDK 21 runs on the same commit are green and this PR only touches the spring boot autoconfigure module, so it looks like an infra timing flake rather than anything from the change.