config-as-code: migrate gate/quality/AI-review mode settings off the DB (settings: + gate: dedup)

[JSONbored]

Part of #6440.

Fields: `reviewCheckMode`, `linkedIssueGateMode`, `duplicatePrGateMode`, `qualityGateMode`, `qualityGateMinScore`, `selfAuthoredLinkedIssueGateMode`, `aiReviewMode`, `aiReviewByok`, `aiReviewProvider`, `aiReviewModel`, `aiReviewAllAuthors`.

These are special: each has BOTH a `settings.` field AND a `gate.` alias (via `applyGateConfigOverrides`), with `gate.*` winning when both are set. Before removing the DB column, decide which manifest path (`settings:` or `gate:`) becomes canonical going forward and deprecate the other, so there's exactly one place to look — not just one fewer (the DB).

[linear-code]

JSO-4440

[JSONbored]

Decision: canonicalize on gate.*, deprecate the settings.* twin for these 11 fields

Resolved the embedded open question. Canonical path going forward: gate.*. settings.* stays
read/DB-persisted (existing .loopover.yml files with the old keys keep working — this is additive
deprecation, not a breaking removal) but stops being documented or accepted as a new manifest key for
these 11 fields.

Reasoning:

• applyGateConfigOverrides (src/signals/focus-manifest.ts:467-518) already makes gate.* win over
  settings.* whenever both are set — every line is independently null-gated, and the doc comment at
  focus-manifest.ts:458-465 confirms this is the intended precedence, not an accident. Canonicalizing on
  the side that already wins is a zero-runtime-behavior-change decision.
• .loopover.yml.example already treats settings: as the generic 1:1 pass-through of the RepositorySettings
  DB row ("Everything a maintainer can toggle in the dashboard can be set here as code",
  .loopover.yml.example:727-731 — 111 fields, no curation), while gate: is the purpose-built,
  hand-curated block that "refines the deterministic gate" (.loopover.yml.example:101-116), with richer
  per-field docs.
• gate: itself already sets this precedent internally: enabled (legacy boolean) is documented as
  deprecated in favor of checkMode — "Prefer setting checkMode explicitly instead of this field"
  (.loopover.yml.example:115). Preferring the purpose-built name over the generic pass-through name is
  already this codebase's convention, not a new one.
• 6 of the 11 fields already have friendlier, curated names under gate: (checkMode / linkedIssue /
  duplicates / readinessMode / readinessMinScore / selfAuthoredLinkedIssue vs. the raw DB-column
  names reviewCheckMode / linkedIssueGateMode / duplicatePrGateMode / qualityGateMode /
  qualityGateMinScore / selfAuthoredLinkedIssueGateMode) — that naming investment is itself evidence
  gate: was meant to be primary. The remaining 5 AI-review fields share identical names on both sides, so
  naming doesn't argue either way for them, but the established precedence + design intent settle it the
  same direction.

Setting this as contributor-eligible: implementing this is now mechanical (stop documenting/accepting the
settings.* twins as new manifest keys for these 11 fields; no runtime behavior changes since gate.*
already wins wherever both are set).