fix(models): honor MODELS_DEV_SYNC_ENABLED=0 over dashboard settings

[RaviTharuma]

Summary

• The comment at the top of src/lib/modelsDevSync.ts already said opt-in via MODELS_DEV_SYNC_ENABLED=true. Nothing in the file read that env var. Periodic sync only looked at settings.modelsDevSyncEnabled in sqlite.
• When GET /v1/models or long-context compression pins the Node event loop, the dashboard is the same process. GET /healthz and GET /dashboard both stop answering (0 bytes / client timeout). Operators cannot open Settings → AI to turn models.dev sync off. That is a catch-22 (fix(ops): /healthz (and other HTTP) times out while event loop is busy (k8s probes flap) #10052, dashboard freeze).
• This PR makes MODELS_DEV_SYNC_ENABLED=0|false|off|no a hard kill switch that wins over the DB. Init skips periodic sync. getModelsDevPricing() returns {} without the SQL + JSON.parse scan so leftover models_dev_pricing rows cannot re-wedge the loop. Unset still honors the dashboard setting. 1|true|on|yes forces sync on.
• Documented in docs/reference/ENVIRONMENT.md. Unit test covers env=0 vs settings=true.

Related Issues

• Related to fix(ops): /healthz (and other HTTP) times out while event loop is busy (k8s probes flap) #10052 (healthz / all HTTP stall)
• Related to fix(api): GET /v1/models pegs event loop — getModelsDevPricing re-reads per model #9685 / fix(models): memoize getModelsDevPricing (event loop / healthz) #10055 (catalog pricing N+1; memoize already on main)
• Related to v3.8.49 still ships the /v1/models event-loop hog; #10055 merged but no 3.8.50 image #10296 (3.8.49 still ships the hog; SemVer not tagged)
• Closes / implements [Feature] Env/CLI kill switch for models.dev sync when HTTP/dashboard is wedged #10301
• Related to [BUG] Dashboard / settings UI freeze with /healthz when catalog or compression hog the event loop #10300 feat(backend): move catalog rebuild work off the App Router request thread #10302 feat(resilience): observe slow healthz responses under event-loop pressure #10303 fix(backend): avoid models.dev sync catalog stalls on supported releases #10304

Validation

• Docs-only change (no production code) — N/A
• Production-code changes include a new or updated automated test in this PR
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• tests/unit/modelsDevSync-extended.test.ts
  • MODELS_DEV_SYNC_ENABLED=0 kills init and getModelsDevPricing even when settings are on
  • existing periodic-sync / init settings tests still pass

node --import tsx --test tests/unit/modelsDevSync-extended.test.ts
# tests 15, pass 15

Coverage Notes

• New branch: env kill switch in initModelsDevSync + getModelsDevPricing + applyModelsDevSyncSection.

Reviewer Notes

• Recovery path for a wedged 3.8.49 (or any build where HTTP is dead): set MODELS_DEV_SYNC_ENABLED=0 and restart. No dashboard, no PATCH /api/settings, no sqlite surgery required.
• Does not replace fix(models): memoize getModelsDevPricing (event loop / healthz) #10055 (memoize) or perf(compression): cap countTextTokens at 50k chars and strip base64 data URIs #10118 (compression). Those still need a SemVer image.
• No secrets or private hostnames.

Test plan

• Unit: env=0 + settings enabled → init does not start timer; getModelsDevPricing() is {} even with rows saved
• Unit: existing init/settings/timer tests still pass
• Manual: MODELS_DEV_SYNC_ENABLED=0 on a box with modelsDevSyncEnabled=true in sqlite → logs [MODELS_DEV] Disabled (MODELS_DEV_SYNC_ENABLED=0), /healthz stays ms-level

[RaviTharuma]

Follow-up links (filed after this PR):

• [Feature] Env/CLI kill switch for models.dev sync when HTTP/dashboard is wedged #10301 is the feature this PR implements (MODELS_DEV_SYNC_ENABLED=0 kill switch).
• [BUG] Dashboard / settings UI freeze with /healthz when catalog or compression hog the event loop #10300 dashboard catch-22 (same event loop as /healthz)
• feat(backend): move catalog rebuild work off the App Router request thread #10302 catalog SWR setTimeout(0) still pins the loop
• feat(resilience): observe slow healthz responses under event-loop pressure #10303 /healthz 3.7s for a 3-byte ok is already sick
• fix(backend): avoid models.dev sync catalog stalls on supported releases #10304 hourly models.dev sync + cache invalidation self-DoS on 3.8.49

No secrets / hostnames in this comment.

[diegosouzapw]

Thanks for chasing this down — the underlying diagnosis is right, and I confirmed two real gaps still exist on release/v3.8.50 today: getModelsDevPricing() doesn't short-circuit on MODELS_DEV_SYNC_ENABLED=0 (still does the full SQL + JSON.parse scan), and applyModelsDevSyncSection() in runtimeSettings.ts only reads the stored setting, so a live PATCH /api/settings can restart the periodic timer even with the kill switch set.

That said, since this branch was opened, MODELS_DEV_SYNC_ENABLED support for initModelsDevSync() already landed on release/v3.8.50 through other work (a separate PR gave it its own docblock and 5 regression tests), and so did the catalog.ts health-check-exclusion filter, the dompurify/nanoid bumps, and the .gitignore _tasks hardening. That's why the diff here is ~191 lines but most of it duplicates what's already on tip, and why GitHub currently shows this PR as conflicting with the base.

Could you rebase onto the current tip and trim the diff down to just the two pieces that are still missing — the getModelsDevPricing() early return and the applyModelsDevSyncSection() env check? A couple of asks while you're in there:

• Reuse the TRUE_ENV_VALUES parsing already in initModelsDevSync() rather than adding a second parallel parser — the file already has a comment explaining why that specific shape was chosen over two other env-override patterns in the repo.
• Add a test for the applyModelsDevSyncSection() path specifically (live PATCH with the kill switch set), since that's the one new behavior without direct coverage in this PR.
• Add MODELS_DEV_SYNC_ENABLED to .env.example if it isn't already there post-rebase — that's what's failing Docs Sync (Strict) right now.

Once it's rebased and scoped down to those two hunks this should be a quick, valuable merge.

[diegosouzapw]

Babysit summary — CI green

Root cause: stale verdict, not a defect. The branch was 2280 commits behind origin/release/v3.8.50; the 5 red checks (Docs Sync (Strict), Build, Unit Tests 2/8 & 4/8, Quality Ratchet) were computed against a pre-base-drift merge result. A refresh-merge cleared them all with no behavioral changes to the fix.

What landed (pushed to RaviTharuma/OmniRoute fork):

• a350a27fd — merge refresh of release/v3.8.50 (resolved conflicts in src/lib/modelsDevSync.ts, its test, ENVIRONMENT.md, .gitignore, package-lock.json). Preserved the PR's MODELS_DEV_SYNC_ENABLED=0 kill-switch + tri-state env parsing, and kept the base's cache-version memoization; re-added the PR's kill-switch regression test.
• 1e4d22861c — prettier formatting restore after the merge base drifted.

Validation: focused modelsDevSync-extended unit test 19/19 pass (incl. the kill-switch test and all base MODELS_DEV_SYNC_ENABLED tests); eslint + prettier clean. No unresolved review threads.

Final gh pr checks 10299: all non-advisory checks pass — Build, Docs Gates, Fast Quality Gates (ratchet), Unit fast-path (1-4/4), Vitest, No-new-ESLint-warnings, dast-smoke, semgrep, Merge integrity, Change Classification. (Mergify prot/queue = skipping, not a failure.)

Ready for human review & merge.