Let a sweep run more than four at a time, and name the run a failure was in

Concurrent runs sat at 4 whatever FLOW_MAX_CASCADES said: that setting bounds
cascades, and the run drivers read a hardcoded MAX_PARALLEL nobody could reach.
FLOW_MAX_RUNS is the knob they read now, --max-runs/--max-cascades/--max-workers
are the same three as flags on serve, and the engine says which numbers it
started with — which is the only way to tell that a settings file was read.

Events keep the run they happened in. The payload always carried it and the
persist path dropped it, so reading one run's failures meant filtering the
engine-wide list; a batch run's id reaches those events now too, since a run
has no journaled item to name itself by.

Also: a provisioner's 0 means "no deadline" rather than "cancel on the next
reconcile", and a command that reaches no engine says how to start one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sbYeYaVgYQqm1sbx7wPdL

backend/fluksio/main.py

@@ -206,8 +206,17 @@ async def lifespan(app: FastAPI) -> AsyncIterator[None]:
         queue=_work_queue("run"),
         state_factory=_run_state,
         artifacts=artifacts,
+        parallel=settings.FLOW_MAX_RUNS,
     )
     app.state.run_service = run_service
+    # Said out loud because it is the only way to tell that a settings file was
+    # read at all — the numbers are what someone raising them is looking for.
+    logger.info(
+        "Engine limits: workers=%s cascades=%s runs=%s",
+        settings.FLOW_MAX_WORKERS,
+        execution.max_cascades,
+        run_service.parallel,
+    )
     watchdog = LoopWatchdog(event_bus)
     app.state.watchdog = watchdog
     watchdog_task = asyncio.create_task(watchdog.run(), name="loop-watchdog")