fix(sse): restore task-aware routing config on restart (#8601)

[MumuTW]

Fixes #8601.

Problem

PUT /api/settings/task-routing persists the T05 Task-Aware Smart Routing config to settings.taskRouting, but nothing ever reads it back. After any restart the feature reverts to enabled: false and the hardcoded DEFAULT_TASK_MODEL_MAP, discarding the operator's configuration.

Two independent root causes — fixing only the first would not have worked.

A. No boot hydration

rg taskRouting -t ts src open-sse returned only the write path and the Zod schema. applyRuntimeSettings does not cover this key, so it needs an explicit hydration step — same as the Global System Prompt (#2470) and the Thinking-Budget config (#5312).

B. Module-level let is duplicated per module graph

let _config: TaskRoutingConfig = { enabled: false, ... };   // taskAwareRouter.ts:171

thinkingBudget.ts:63-68 documents why this breaks: a module-level binding is duplicated per graph, so boot hydration on the instrumentation graph never reaches the copy src/sse/handlers/chat.ts:573 reads. This is the exact failure #5312 fix-A hit on the VPS.

Fix

• taskAwareRouter.ts — move the config store to the globalThis pattern used by thinkingBudget.ts and systemPrompt.ts; add hydrateTaskRoutingConfig(settings), accepting either the JSON string the route writes or an already-parsed object, failing open on malformed input. Runtime stats are never restored from the persisted blob.
• src/instrumentation-node.ts — call it next to the Thinking-Budget restore. Wired into the real boot path, not the unused src/server-init.ts (called out as unused at instrumentation-node.ts:366 / :407).

No behavior change when nothing is persisted: the in-memory defaults stay in place, and the feature remains off by default.

Validation (Hard Rule #18 — TDD)

tests/unit/task-routing-config-restore-8601.test.ts, 5 cases. Written first, confirmed red:

SyntaxError: The requested module '.../taskAwareRouter.ts'
does not provide an export named 'hydrateTaskRoutingConfig'

Green after the fix — 20/20 including the pre-existing chat-route-coverage suite:

node --import tsx/esm --test tests/unit/task-routing-config-restore-8601.test.ts \
                              tests/unit/chat-route-coverage.test.ts
# tests 20 / # pass 20 / # fail 0

The cross-module-graph case (root cause B) was separately proven to have teeth — importing a module under two distinct specifiers does yield two real instances, so the test would fail on the old let-based store:

module-let  -> A: true   B: false     <- not shared (the bug)
globalstore -> A: true   B: true      <- shared (the fix)

Gates

• npm run typecheck:core — clean
• npx eslint on changed files — 4 no-explicit-any, all pre-existing (4 on the base ref, 4 after; eslint-suppressions.json already records count: 4 for this file). No new violations, no baseline update needed.

[MumuTW]

The two red checks are pre-existing base breakage, not this PR

Fast Quality Gates and Unit Tests fast-path (2/4) fail identically on the base commit itself. Verified by running both on a pristine worktree at 4053e2314 with no changes from this PR:

Check	Pristine base 4053e2314	This PR's CI
check:complexity-ratchets	complexity=2169 / cognitiveComplexity=956	complexity=2169 / cognitiveComplexity=956
tests/unit/serial/combo-quota-share-cooldown-wait-timing.test.ts	2 pass / 2 fail — 429 !== 200, 403 !== 429	same two assertions

Byte-identical. Unrelated PR #8599 fails on the same two jobs in the same CI window.

Already tracked, no new issue filed:

• fix(quality): release branch not green — DB rules violation in compressionDetailNormalizers.ts #8540 — release branch not green; lists these exact numbers (956 vs baseline 951, complexity=2169) and classifies them as "Ratchet drift (non-blocking — rebaseline at release) … NOT a contributor concern"
• fix(resilience): combo cooldown-wait gate still quota-share/auto only, contradicting its own "ALL strategies" contract (#7301) #8541 — the failing combo-quota-share-cooldown-wait-timing cases
• fix(quality): absolute baselines make inherited drift red every PR — red stops being a signal #8522 — absolute ratchet baselines make inherited drift red on every PR
• fix(ci): base-red compounds because fast-gates fail-fast hides later gates, and PRs land while red #8542 — fast-gates fail-fast hides later gates

Per #8542, a green board can't be the evidence here — the fail-fast masks downstream gates. Local validation for this PR:

node --import tsx/esm --test tests/unit/task-routing-config-restore-8601.test.ts \
                              tests/unit/chat-route-coverage.test.ts
# tests 20 / # pass 20 / # fail 0

npm run typecheck:core     # clean
npx eslint <changed files>  # 4 no-explicit-any, all pre-existing (suppressions record count: 4)

Everything else on this PR is green: Vitest, Unit 1/3/4, ESLint, Docs Gates, Merge integrity, semgrep, dast-smoke.

[diegosouzapw]

Closing — this change shipped inside #8605

Thanks for this — it was a real fix, and it did land. Verified against origin/release/v3.8.49:

open-sse/services/taskAwareRouter.ts:187   // #8601: the config MUST live on globalThis, NOT a module-level `let`
open-sse/services/taskAwareRouter.ts:248   export function hydrateTaskRoutingConfig(settings: unknown): boolean
src/instrumentation-node.ts:410-412        const { hydrateTaskRoutingConfig } = ... if (hydrateTaskRoutingConfig(settings))

The reason this PR stayed open is worth recording: the squash commit of #8605 (merged today) carries as its first sub-commit exactly fix(sse): restore task-aware routing config on restart (#8601) — the content of this PR. #8605 incorporated this branch before submitting, so the work merged under that PR's number rather than this one.

Closing as merged-via-#8605. The boot-time hydration is live on the release branch.