fix(scheduler): revive dead brain-init executions in ~6m instead of 30m

The window before db-scheduler reclaims an execution whose owner died is
heartbeat-interval × missed-heartbeats-limit. At 5m × 6 that was thirty minutes.

During it a dead brain-init stage is invisible rather than failed: the
init-status endpoint keeps returning the last stage and percentage it reached,
with completedAt null and errorMessage null, so a frozen run is indistinguishable
from a slow one. smoke-test.sh waits 1200s (20m) — less than the revival window —
so any run in which a stage died failed the smoke test even though initialization
would have finished normally once revived. Observed exactly that: a stage stopped
heartbeating, the smoke test timed out at 74%, and brain init then completed at
100% roughly 37 minutes after the scheduler revived it.

1m × 6 keeps the same six-missed-heartbeat tolerance and brings revival to about
six minutes, comfortably inside the smoke-test window. Shortening the interval
does not risk reclaiming healthy work: heartbeats are sent from the execution's
own thread, so a long-running LLM call keeps heartbeating and is never mistaken
for a dead owner.

Only the heartbeat interval changes. application-test.properties overrides
polling-interval and immediate-execution-enabled, not these keys, so tests are
unaffected.

Author: geekypunk

backend/src/main/resources/application.properties

@@ -71,7 +71,19 @@ spring.batch.job.enabled=false
 
 # db-scheduler Configuration (distributed task scheduling)
 db-scheduler.enabled=true
-db-scheduler.heartbeat-interval=5m
+# The revival window for an execution whose owner died is
+# heartbeat-interval × missed-heartbeats-limit. At the old 5m × 6 that was THIRTY
+# MINUTES, during which a dead brain-init stage sits at a frozen percentage with no
+# error: the status endpoint keeps reporting the last stage it reached, so it is
+# indistinguishable from slow progress. smoke-test.sh gives up after 1200s (20m),
+# so any run where a stage died failed the smoke test even though init would have
+# completed fine once revived — observed exactly that, init finishing ~37m after
+# revival.
+#
+# 1m × 6 keeps the same six-missed-heartbeat tolerance — a live-but-slow execution
+# heartbeats from its own thread, so a long LLM call is never mistaken for death —
+# while bringing revival to ~6m, comfortably inside the smoke-test window.
+db-scheduler.heartbeat-interval=1m
 db-scheduler.missed-heartbeats-limit=6
 db-scheduler.polling-interval=10s
 db-scheduler.polling-strategy=fetch