fix(core): bound startup recovery wait in shutdown to 15s

[kiwipaulrob]

Problem

core.shutdown() awaited startupRecoveryPromise with no timeout. With a large dirty episode and a slow/flaky LLM, the startup-recovery reflect chain (up to 163 sequential LLM calls at ~2min each) can take minutes — holding shutdown hostage until the systemd kill timer fires.

Observed 15 Aug 2026 on a production bridge: SIGTERM at 08:00:23, daemon stuck mid-recovery, systemd TimeoutStopSec=600 expired, SIGKILL at 08:10:23. A 10-minute stop-sigterm wedge from a single unguarded await.

Fix

Wrap the recovery wait in the existing withTimeout() helper (15s):

await withTimeout(startupRecoveryPromise, 15_000, "startup_recovery_shutdown_timeout");

Why 15s is safe:

• The wait was introduced for issue fix: [memos-local-plugin] Dreaming background processing starves Gateway event loop, causing WebSocket timeouts #1808 to prevent a fast init → shutdown race closing SQLite mid-flush. A 15s grace still covers that (recovery of 0–1 episodes finishes in ms).
• Recovery is resumable by design: dirty episodes carry rewardDirty.failedAttempts, and the periodic 10-minute rescore re-runs them. Proceeding after the grace loses no data.
• After the timeout, handle.shutdown() detaches subscribers and the daemon's process.exit(0) fires — lingering LLM calls can no longer hold the process hostage.

Verification

• tsc --noEmit clean
• Full unit suite: 168 files / 1365 tests passed (incl. the issue fix: [memos-local-plugin] Dreaming background processing starves Gateway event loop, causing WebSocket timeouts #1808 recovery-stall test)
• Production companion change: TimeoutStopSec tightened 600s → 90s on the systemd unit (ops-side belt-and-braces; with this fix graceful shutdown completes in ~20s)

[Memtensor-AI]

✅ Automated Test Results: PASSED

All tests passed (41/41 executed). memos_local_plugin/unit: 41/41. Duration: 12s

Branch: fix/shutdown-recovery-timeout