Investigate + close the config-as-code gap for reviewMemory

[JSONbored]

Part of #4092.

Confirmed finding (was originally filed as an open investigation — now resolved by direct code-check)

review-memory-wire.ts:27: return isReviewMemoryEnabled(env) && manifestReviewMemoryEnabled; — review.reviewMemory IS already consulted for the real on/off decision, but only as a REQUIRED additional AND-gate alongside GITTENSORY_REVIEW_MEMORY, same pattern as inlineComments/fixHandoff (#4099) — not the fully-dead features.* pattern this epic also found elsewhere. A repo can restrict via config but can't fully replace the env var.

Fix

Same shape as #4099: apply src/review/feature-activation.ts's existing precedence (env kill-switch → per-repo override → allowlist default) so review.reviewMemory: true can turn the feature on for a repo even without the env var/allowlist, and false forces it off. Resolve the same namespace question #4099 raises (migrate into features: vs. keep the existing top-level field name with upgraded resolution logic) — for consistency, whatever #4099 decides for inlineComments/fixHandoff should apply here too.

Deliverables

• isReviewMemoryEnabled's real gate migrated to the resolver's full precedence
• Regression test: unset config preserves EXACT current behavine for every existing repo
• Tests mirroring the feature-activation pattern

Expected outcome

review.reviewMemory fully controls the feature per-repo, consistent with the namespace decision made in #4099.

Effort

S — confirmed, well-defined fix; no further investigation needed.

[linear-code]

JSO-3151

[JSONbored]

Closing as investigated, no code change warranted — the issue's premise doesn't hold, and PR #4123 (opened against this issue) is being closed unmerged for the same reason.

The claim: shouldApplyReviewMemory's isReviewMemoryEnabled(env) && manifestReviewMemoryEnabled is "the same pattern as inlineComments/fixHandoff (#4099)" and needs the same fix so review.reviewMemory: true can turn the feature on "even without the env var."

Why this doesn't hold, verified against the actual merged #4116 diff (gh pr diff 4116): inlineComments/fixHandoff's OLD code was manifestToggle === true && isXEnabled(env) && isConvergenceRepoAllowed(env, repoFullName) — a REAL three-way AND that included the GITTENSORY_REVIEW_REPOS cutover allowlist. Dropping that allowlist term was the actual fix: a repo not on the shared allowlist could never turn the feature on before #4116, even with an explicit manifest override — that's a genuine behavioral gap closed.

reviewMemory never had an allowlist term. resolveReviewMemoryManifestToggle (src/signals/focus-manifest.ts:290-292) already collapses to a definite boolean — manifest?.review.reviewMemory === true — before it ever reaches the AND-gate. So the "required AND" here is just envFlag && definiteBoolean, which is algebraically identical to any "kill-switch, then let the manifest decide" shape for every possible input: unset ⇒ false either way, explicit true ⇒ on either way (subject to the SAME absolute env kill-switch either way — #4116 never let manifest bypass the env var either, only the allowlist). There is nothing to gain from a rewrite; review.reviewMemory already fully controls this feature today, the same way #4116 made inlineComments/fixHandoff work.

This was caught by the gittensory-orb bot's own review of PR #4123: a real, correct blocker (Gate result: Blocking) pointing out that "no runtime gating behavior actually changes... exactly the old 'narrow only' behavior being described as fixed." An adversarial second pass independently confirmed the bot was right, not a false positive.

review.reviewMemory already fully controls this feature (subject to the operator kill-switch), no code change needed.