fix(routines): hot-enable on LLM key save — resolve chat agent live per run

[SecurID]

Fixes #473

Problem

Routines was the only feature that couldn't hot-enable when the LLM key is saved: the kernel wired it once at boot behind if (graphPool && orchestrator), capturing the orchestrator by reference. On a fresh install (key entered post-boot via the Setup Wizard) routines stayed dark until a manual restart — the boot log literally said "then restart to enable routines". This was the last manual step in the first-run flow (follow-up from #471).

Approach — chat's live-resolution pattern

• initRoutines / RoutineRunner take a getOrchestrator live resolver (closure over serviceRegistry.get('chatAgent')?.raw, mirroring the chat routes' getChatAgentBundle) instead of a captured instance. The boot gate is now graphPool-only; stores, router, manage_routine tool, cron registration, and catch-up all initialize at boot regardless of key state.
• Zero hot-enable trigger code: the moment the key save reactivates the orchestrator plugin and republishes chatAgent@1, the next cron fire just works. A key rotation (reactivate publishes a new bundle) is picked up the same way; each run pins the instance current at fire time.
• Keyless fires record an error run naming the missing key — consistent with One-click deploy (Render + Fly.io) — and the four first-run fixes it surfaced #471's "fresh installs say what's missing". The chat-agent check runs before the sender lookup because pre-key the channel plugins (requires: chatAgent@^1) are dark too, and the old order would report a misleading no proactive sender. The pause/delete re-read now runs first, so a raced fire on a just-paused row stays a silent skip.
• POST /:id/trigger returns a synchronous 503 routines.chat_unavailable instead of a fire-and-forget 202 whose run is guaranteed to fail; the web-ui maps the code to a catalog message (EN/DE) instead of rendering the raw error.
• Removed the stale "restart to enable routines" log line and updated the kernel design comment that documented this exact gap.

Tests

7 new (all green, full middleware suite 4018 pass / 0 fail; web-ui typecheck, vitest, i18n:check pass):

• keyless fire → error run with the structured message, asserting the chat check precedes the sender lookup
• hot-enable flip: fire fails keyless, resolver starts returning an agent, next fire succeeds on the same scheduler entry — the Routines don't hot reload on startup #473 behavior pin
• key rotation: consecutive fires use the instance current at fire time
• trigger route: 503 while unavailable, 404 precedence, 503→202 flip on the same router instance (router-level analog of chatSessionsRouterGraceful.test.ts)

Notes

• Fully independent of One-click deploy (Render + Fly.io) — and the four first-run fixes it surfaced #471 (zero file overlap; verified git diff main...feat/one-click-deploy is empty for every touched file).
• Accepted edges (by design): a high-frequency routine accumulates one error run per fire while keyless; a fire in the seconds-wide window between chatAgent publish and channel-sender re-registration records one UnknownChannelError run and self-heals on the next fire.

🤖 Generated with Claude Code