feat: add Codex Fast mode setting

[niffyord]

What & why

Add an opt-in, live Codex Fast mode setting for latency-sensitive scans.

Operators can turn Fast mode on or off from Settings without recreating the engine container. Native Codex scan and structured-output resume calls receive features.fast_mode=true and service_tier="fast"; OpenRouter-backed Codex calls and tool-free generation keep their existing behavior.

The toggle is intentionally explicit and warns that supported models consume credits at a higher rate. It follows the Codex Fast mode configuration.

Type of change

• fix — bug fix
• feat — new feature
• docs — documentation only
• refactor / chore / test / ci
• Breaking change (! / BREAKING CHANGE:)

Affected components

• frontend
• backend
• engine
• database (migration)
• docs / CI / tooling

Checklist

• Commits use Conventional Commits (no empty () scope)
• Commits are signed off (git commit -s) — DCO
• Lint & format pass (npm run lint / ruff check .)
• Tests added/updated and passing where it makes sense
• Docs updated if behavior or config changed
• For DB changes: additive, IF NOT EXISTS-guarded migration in database/init/, Prisma schema updated, and migrate.js re-runs cleanly (idempotent)
• No secrets committed

Notes for reviewers

Runtime behavior:

• the worker reads the setting whenever it creates a scan harness, so future calls—including later calls in a running scan—use the new value
• already-running model calls are not interrupted or changed
• Codex remains responsible for model/account eligibility
• the deployment default is ENGINE_CODEX_FAST_MODE=false

Validation:

• backend runtime settings tests: 6 passed
• backend ESLint: passed
• frontend runtime settings tests: 8 passed
• frontend ESLint: passed
• frontend production build: passed
• engine focused suite: 59 passed
• Ruff format/check on changed engine files: passed

[GabiCtrlZ]

Looks good! One concern before merge: Fast mode is enabled for every native Codex scan, but service_tier = "fast" is only valid when the selected model/account advertises that tier. Our model catalog currently doesn’t retain service-tier capability data, so an unsupported native model may fail instead of staying on the standard tier.

Could you add a compatibility guard (or confirm/document Codex’s fallback behavior) and cover an unsupported native model in tests?