Wire review.features.safety into isSafetyEnabled's actual gate

[JSONbored]

Part of #4092. Depends on the core resolver issue (config-as-code resolver).

Problem

review.features.safety (packages/gittensory-engine/src/focus-manifest.ts:176) is parsed but isSafetyEnabled (src/review/safety.ts:44) checks ONLY GITTENSORY_REVIEW_SAFETY. A repo can't opt in/out of the safety-checks feature through .gittensory.yml.

Fix

Wire manifest.features.safety through the shared resolver into isSafetyEnabled's decision.

Deliverables

• isSafetyEnabled (or its caller) consults manifest.features.safety via the shared resolver
• Tests: config true/false/unset across allowlisted and non-allowlisted repos
• Confirm no safety-critical invariant regresses when a repo can now enable this via config alone (review what safety.ts actually gates before wiring, since "safety" checks may be exactly the kind of thing that should stay a stronger/more conservative default than other features — flag if so rather than assuming symmetry with the others)

Expected outcome

An operator can turn the safety-checks feature on/off per-repo purely through config, with the same care given to defaults as the other features in this epic.

Effort

S — one gate function + tests, plus a safety-default review.

[linear-code]

JSO-3148

[JSONbored]

Closing as already resolved — verified this one most carefully given the safety-sensitivity flagged in the original issue. `convergedFeatureActive(env, repoFullName, "safety")` is already the real gate (src/services/ai-review.ts ~line 1825), and `feature-activation.ts` already implements exactly the asymmetric safeguard this issue asked me to double-check: a repo-controlled `features.safety: false` override is downgraded to "no opinion" (falls through to the allowlist default) rather than an active force-off, specifically because `.gittensory.yml` is repo-writable, lower-trust than the operator (#2386). No fix needed — this is in better shape than I assumed.