config-as-code: expose gate:-only fields under settings:, resolve firstTimeContributorGrace

[JSONbored]

Part of #6440.

Fields with NO `settings.` equivalent today, reachable only via the secondary `gate:` block: `gatePack` (`gate.pack`), `slopGateMode`/`slopGateMinScore`/`slopAiAdvisory` (`gate.slop.`), `mergeReadinessGateMode` (`gate.mergeReadiness`), `manifestPolicyGateMode` (`gate.manifestPolicy`), `linkedIssueSatisfactionGateMode` (`gate.linkedIssueSatisfaction` + `review.linkedIssueSatisfaction` fallback), `requireFreshRebaseWindowMinutes` (`gate.requireFreshRebaseWindow`), `aiReviewLowConfidenceDisposition` (`gate.aiReview.lowConfidenceDisposition`).

First: confirm each is actually wired through `applyGateConfigOverrides` (unconfirmed by the initial audit pass — only the `settings:`-paired aliases were independently traced). Then: give each a `settings.*` field to match the dual-path pattern already established elsewhere, OR consolidate on `gate:` alone and update docs — pick one canonical location, don't just add a second.

Also in scope: `firstTimeContributorGrace` is parsed via `gate.firstTimeContributorGrace` but marked RESERVED/INERT (#2266) — never read by the gate evaluator. Either wire it into the evaluator for real, or remove the dead parsing/manifest surface so `.loopover.yml` stops implying a working toggle.

[linear-code]

JSO-4442

[JSONbored]

Decision 1: consolidate on gate: alone — no new settings.* twins for these 7 fields

Resolved the embedded open question. No settings.* equivalents added for gatePack,
slopGateMode/slopGateMinScore/slopAiAdvisory, mergeReadinessGateMode, manifestPolicyGateMode,
linkedIssueSatisfactionGateMode, requireFreshRebaseWindowMinutes, aiReviewLowConfidenceDisposition.
All 7 are confirmed wired through applyGateConfigOverrides (focus-manifest.ts:475-517) and already
have DB columns + dashboard UI
(apps/loopover-ui/src/components/site/app-panels/maintainer-settings.tsx,
apps/loopover-ui/src/lib/maintainer-settings-editable.ts) — so the "dashboard gap" a settings.* twin
would supposedly close doesn't actually exist; only the yml settings: block lacks these keys, and per
#6444's decision that's fine, gate: is canonical there too.

Adding a second path here would recreate the exact dual-path ambiguity this milestone (#6440) exists to
remove. linkedIssueSatisfactionGateMode is the cautionary example already living in this codebase: it has
a third, near-duplicate path (manifest.review.linkedIssueSatisfaction, focus-manifest.ts:618-626,
doc-commented as "a near-identically-named but functionally distinct phantom field") — proliferating paths
for the same setting is exactly what costs clarity, not what buys it.

Decision 2: firstTimeContributorGrace — delete the dead surface, don't wire it

Git history shows this was a real feature (PR #552 / 4496707ec) later deliberately gutted by #2411
(6ecacecef): evaluateGateCheckCore never reads policy.firstTimeContributorGrace — a deliberate
removal ("blocker findings must remain closure/rejection outcomes"), not an oversight. That's a settled
architectural principle of the one-shot gate, also affirmed in this repo's own CLAUDE.md
("auto-CLOSED, one-shot"). #5321 already spent a PR just disclosing the inertness in the dashboard.

Decision: delete the dead parsing/manifest/DB/dashboard surface for firstTimeContributorGrace
entirely, rather than re-wire it — re-wiring would reintroduce a softened-block exception against a
settled design decision the gate deliberately does not have.

Setting this as contributor-eligible: both decisions are now mechanical — consolidate-on-gate: (no new
fields to add) plus a delete-the-dead-surface cleanup (parsing, manifest type, DB column, dashboard
disclosure UI added by #5321). No remaining open design question.