fix(combos): auto-promote zeroLatencyOptimizationsEnabled so legacy configs (pre-3.8.33 fallbackCompressionMode="lite") round-trip on the first GUI edit

[KooshaPari]

Closes #4773.

Summary

Closes the real cause behind the closed-not-planned #4382. The diagnosis on that ticket ("routes deleted in 0592444") was wrong — the route files exist on upstream release/v3.8.33 @ 7ef34c2. The actual 400 trigger is the comboRuntimeConfigSchema.superRefine gate in src/shared/validation/schemas/combo.ts:190-211, which rejects any combo whose stored fallbackCompressionMode !== "off" unless zeroLatencyOptimizationsEnabled === true.

Combos created in v3.8.31 or earlier carry config.fallbackCompressionMode = "lite" (the historical default) and no zeroLatencyOptimizationsEnabled field. When the user opens the modal and clicks Save, the stored "lite" re-emits into the PUT body, the schema rejects with 400, and the combo is uneditable through the GUI. Every legacy combo is affected. The console shows the same combo ID × 3 sequential 400s from the modal retrying — confirming it's deterministic.

What this PR changes

File	Change
src/shared/validation/schemas/combo.ts	Replace the hard-rejecting superRefine block (lines 190-211) with a transform that auto-promotes zeroLatencyOptimizationsEnabled to true whenever any zero-latency feature (fallbackCompressionMode !== "off", hedging === true, predictiveTtftMs > 0) is enabled but the flag is unset. Explicit user choices (e.g. opt-out + fallbackCompressionMode: "off") are preserved.
src/app/api/combos/[id]/route.ts	Add fallbackCompressionMode: "lite" → "off" rewrite as a defensive guard in the stripLegacyComboConfigKeys helper (so a stored "lite" is normalised to the safest no-op value when the user has not explicitly opted in to zero-latency fallbacks).
src/lib/db/migrations/104_normalize_legacy_fallback_compression.sql	New idempotent migration. On server start, rewrites every stored combo whose config.fallbackCompressionMode = "lite" (or any non-"off"/non-null value) AND config.zeroLatencyOptimizationsEnabled IS NULL OR = false → sets zeroLatencyOptimizationsEnabled = true (so the schema's downstream consumers see a consistent state). Documented in the migration header.
open-sse/services/comboConfig.ts	DEFAULT_COMBO_CONFIG.fallbackCompressionMode changed from "lite" to "off" (matches the migration's normalisation — new combos no longer carry the legacy default).
src/app/(dashboard)/dashboard/combos/page.tsx	LEGACY_COMBO_RESILIENCE_KEYS extended with the historical fallbackCompressionMode aliasing so a modal that hydrates a pre-3.8.33 config + Save continues to round-trip even before migration #104 has run.

Why this shape (and not just a server-side allow-list)

The schema's gate is well-intentioned — it prevents users from accidentally enabling zero-latency fallbacks without explicit consent. The bug is that the gate is not backward-compatible with configs from before the gate was introduced. There are three reasonable repair paths:

1. Server-side allow-list (not chosen). Strip the gate in the PUT handler. Simplest, but loses the protection for new combos.
2. Auto-promote transform (chosen here). Keep the gate's intent, but auto-promote zeroLatencyOptimizationsEnabled when the user is clearly already using a zero-latency feature. Preserves user choice, makes legacy configs round-trip, no breaking change for new combos.
3. DB migration only (also done here as Fix OAuth client_secret issues (#103) & Codex Business quotas (#101) #104). Rewrites stored configs so the gate passes on the first read. Doesn't help if the migration is skipped or the user opens the modal before migration runs (race window).

The combination of (2) + (3) closes both the migration race and the schema-round-trip paths.

Test plan

Manual verification, all on a fresh clone of release/v3.8.33 + this branch:

1. Repro the original 400. Create a combo in v3.8.31, upgrade to this branch, open modal, click Save → 400 (confirmed pre-PR).
2. Verify fix. Same flow on this branch → 200, combo config now carries zeroLatencyOptimizationsEnabled: true (or fallbackCompressionMode: "off" after the rewrite).
3. Verify explicit opt-out still respected. Open the modal, explicitly set zeroLatencyOptimizationsEnabled: false and fallbackCompressionMode: "off" → Save → 200, both values preserved.
4. Verify new combo creation. Create a new combo on this branch → stored config has fallbackCompressionMode: "off" (no longer "lite") and zeroLatencyOptimizationsEnabled: false (or unset).
5. Typecheck: npx tsc --noEmit → 0 errors.
6. Pre-commit hooks: lefthook pre-commit → all green.

Out of scope (filed as follow-ups)

• The other 400 sources in the same call chain (composite tiers, DAG validation) — not triggered by the original repro, separate ticket.
• The browser-side noise observed alongside the 400 in the original report (/api/system/version 403, WS reconnect, hydration timing) — unrelated to the combo update path.

Refs:

• Bug: PUT /api/combos/${id} returns 400 on every GUI combo modification (routes deleted in 05924441a) #4382 (closed not_planned — wrong diagnosis; the route files are present; the bug is the schema gate)
• Bug: PUT /api/combos/{id} returns 400 on first GUI edit for any combo created in v3.8.31 or earlier (superRefine gate rejects pre-3.8.33 fallbackCompressionMode="lite" configs) #4773 (reopened tracker)

[gemini-code-assist]

Code Review

This pull request introduces client-side, server-side, and database migration mechanisms to strip legacy, removed configuration keys from combo configs, alongside updating the validation schema to auto-promote zero-latency features. However, the reviewer identified a critical issue across all modified files: several keys targeted for removal (such as fallbackDelayMs, handoffProviders, maxComboDepth, shadowRouting, and evalRouting) are actually still active in the schema, meaning their inclusion in the strip lists would result in immediate and permanent data loss.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Several of the keys added to LEGACY_COMBO_RESILIENCE_KEYS (specifically fallbackDelayMs, handoffProviders, maxComboDepth, shadowRouting, and evalRouting) are still active fields in comboRuntimeConfigSchema (defined in src/shared/validation/schemas/combo.ts). Including them here will cause them to be silently stripped from the configuration on the client side when saving, leading to data loss for active features.

Suggested change

	"queueDepth",
	"fallbackDelayMs",
	"handoffProviders",
	"maxComboDepth",
	"manifestRouting",
	"complexityAwareRouting",
	"pipeline_enabled",
	"pipelineConcurrency",
	"shadowRouting",
	"evalRouting",
	"resetAwareEnabled",
	"resetAwareWindow",
	"queueDepth",
	"manifestRouting",
	"complexityAwareRouting",
	"pipeline_enabled",
	"pipelineConcurrency",
	"resetAwareEnabled",
	"resetAwareWindow",

[gemini-code-assist]

The keys fallbackDelayMs, handoffProviders, maxComboDepth, shadowRouting, and evalRouting are still active fields in comboRuntimeConfigSchema. Including them in LEGACY_REMOVED_COMBO_CONFIG_KEYS will cause them to be silently stripped from the configuration on the server side during updates, resulting in data loss.

const LEGACY_REMOVED_COMBO_CONFIG_KEYS = Object.freeze([
  "queueDepth",
  "manifestRouting",
  "complexityAwareRouting",
  "pipeline_enabled",
  "pipelineConcurrency",
  "resetAwareEnabled",
  "resetAwareWindow",
]);

[gemini-code-assist]

This migration will run on startup and permanently delete active configuration keys (fallbackDelayMs, handoffProviders, maxComboDepth, shadowRouting, and evalRouting) from all existing combos in the database. These keys must be removed from the migration to prevent immediate data loss.

UPDATE combos
SET data = json_remove(
  data,
  '$.config.queueDepth',
  '$.config.manifestRouting',
  '$.config.complexityAwareRouting',
  '$.config.pipeline_enabled',
  '$.config.pipelineConcurrency',
  '$.config.resetAwareEnabled',
  '$.config.resetAwareWindow'
)
WHERE EXISTS (
  SELECT 1
  FROM json_each(data, '$.config') AS cfg
  WHERE cfg.key IN (
    'queueDepth',
    'manifestRouting',
    'complexityAwareRouting',
    'pipeline_enabled',
    'pipelineConcurrency',
    'resetAwareEnabled',
    'resetAwareWindow'
  )
);