docs(review): resolve the review.linked_issue_satisfaction / gate.linkedIssueSatisfaction phantom-field confusion

[JSONbored]

Context

Found while auditing review-control wiring for #1681. There are two distinctly-named
linked-issue-satisfaction fields, and only one of them does anything:

• gate.linkedIssueSatisfaction (.gittensory.yml) overrides RepositorySettings.linkedIssueSatisfactionGateMode
  — this is the real, DB-backed, dashboard-settable gate mode that actually runs the assessment and
  (in block mode) can gate a PR. Confirmed live and recently deepened by feat(review): wire linked-issue satisfaction into the deterministic gate #4069.
• review.linkedIssueSatisfaction (.gittensory.yml, the FocusManifestReviewConfig field, feat(config): add review.linkedIssueSatisfaction config knob (off/advisory/block, default off) #2173) is
  parsed but never read anywhere — setting it today does nothing, silently.

The near-identical names make it easy for a self-host operator to set the wrong one and get no error and
no effect.

Evidence

• src/types.ts:761-769 explicitly documents the two as distinct: linkedIssueSatisfactionGateMode's
  doc comment says "Distinct from the config-as-code-only review.linkedIssueSatisfaction manifest field
  (feat(config): add review.linkedIssueSatisfaction config knob (off/advisory/block, default off) #2173) — this is the DB-backed, dashboard-settable gate-mode counterpart; .gittensory.yml gate.linkedIssueSatisfaction overrides it exactly like every other gate: field."
• Every real consumer in src/queue/processors.ts (e.g. :6638, :7949, :8978) reads
  settings.linkedIssueSatisfactionGateMode — none reads manifest.review.linkedIssueSatisfaction.
• resolveReviewPromptOverrides (src/signals/focus-manifest.ts:250), the resolver every other
  review.* prompt/display field flows through, does not include linkedIssueSatisfaction in its
  returned shape at all.
• Re-verified against current main (post-feat(review): wire linked-issue satisfaction into the deterministic gate #4069): that PR wired gate.linkedIssueSatisfaction deeper
  into the deterministic gate, but did not touch the separate review.linkedIssueSatisfaction manifest
  field.

The ask

Pick one:

1. Fold it in as an alias: treat review.linkedIssueSatisfaction as a settings-layer alias for
   gate.linkedIssueSatisfaction, following the same gate: > settings: precedence pattern already
   used for every other typed gate.* alias (see applyGateConfigOverrides in
   src/signals/focus-manifest.ts), so setting either spelling has the same real effect.
2. Remove the phantom field: drop review.linkedIssueSatisfaction from the manifest schema/parser
   and docs so there is exactly one place (gate.linkedIssueSatisfaction) to set this, removing the
   confusable near-duplicate.

Not presuming which — flagging so a maintainer can decide.

Related

• Found during feat(review): test review controls end to end #1681 (review-controls end-to-end test audit).
• Distinct from feat(review): wire linked-issue satisfaction into the deterministic gate #4069 (which wired the gate.* field, not this one) and feat(config): add review.linkedIssueSatisfaction config knob (off/advisory/block, default off) #2173 (which introduced the
  review.* field's parsing).

[linear-code]

JSO-3169