feat(review): wire labelingRules to a real label-suggestion evaluator, or remove the dead config field

[JSONbored]

Context

Found while auditing review-control wiring for #1681. .gittensory.yml's review.labeling_rules is
fully parsed and validated, but has zero real consumer anywhere in src/ — setting it today has no
runtime effect at all, silently.

Evidence

• Parsed + validated: parseReviewLabelingRules (packages/gittensory-engine/src/focus-manifest.ts:2251),
  called from parseReviewConfig (:2002), producing a real LabelingRule[] on
  FocusManifestReviewConfig.labelingRules.
• grep -rn "LabelingRule" src/ returns only the type's re-export in src/signals/focus-manifest.ts —
  no function anywhere reads manifest.review.labelingRules or does anything with a LabelingRule.
• Contrast with every other review.* field (e.g. review.tone, review.exclude_paths), which is
  resolved by resolveReviewPromptOverrides and threaded into a real call site
  (src/queue/processors.ts) — labelingRules has no equivalent resolver call at all.

The ask

Pick one:

1. Wire it: add a real label-suggestion evaluator that reads FocusManifestReviewConfig.labelingRules
   (condition -> label) and applies it somewhere in the labeling pipeline (the existing typeLabels
   auto-label path in src/queue/processors.ts is the closest analogue to follow), with the config-as-code
   parity this repo requires for a new gate/setting field (settings resolver + tests covering the
   resolution + the actual labeling behavior).
2. Deprecate/remove it: if there's no product plan to wire per-rule labeling this way, drop
   review.labeling_rules parsing/validation/types and its docs, so a self-host operator who sets it
   gets a clear "unknown field" signal instead of a silent no-op.

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).

[linear-code]

JSO-3167