CostBasedScheduleGenerator blocks an Akka dispatcher thread at startup

### Task Summary
`createRegionDAG()` runs the region-plan search in a `Future` and blocks on `Await.result(..., searchTimeoutMilliseconds)` (`CostBasedScheduleGenerator.scala:318`). It runs once per workflow execution from `Controller.preStart` -> `initState` on the actor dispatcher, bounded by `schedule-generator.search-timeout-milliseconds` (default 1000ms).

The `Await` is intentional: it enforces that timeout and falls back to greedy `bottomUpSearch` on `TimeoutException`, so it cannot simply be deleted. The concern is that it parks a shared Akka dispatcher thread for up to ~1s at startup, which can momentarily steal a pool thread from other co-located actors/workflows.

A fully non-blocking version would require threading a `Future` through `WorkflowScheduler.updateSchedule`, `Controller.initState`, and downstream consumers that immediately read `getSchedule`, which is invasive (actor `preStart` cannot cleanly await). Open question for discussion: is the ~1s startup block worth that refactor, or is a lighter mitigation (dedicated dispatcher / `scala.concurrent.blocking {}` hint) sufficient?
### Task Type
- [x] Performance