Spec: gittensor-enrollment-aware planning enrichment (optional input, zero footprint when disabled)

[JSONbored]

Problem

A repo that has opted into gittensor (.loopover.yml's experimental.gittensor: true, gated by src/review/gittensor-wire.ts) has richer context available (registry/subnet data via src/registry/sync.ts) that could make generated issue plans more relevant — e.g. suggesting gittensor:* labels/scoring conventions where appropriate. The planning tool from sub-issue 2 must still work identically well on a plain, non-enrolled repo; gittensor must never become a hidden requirement.

Area

src/review/gittensor-wire.ts, src/registry/sync.ts, sub-issue 2's planning tool.

Proposal

• When shouldEnableGittensorForRepo(repo) is true for the target repo, sub-issue 2's tool pulls in gittensor registry context as additional planning input (e.g. suggesting gittensor:* labels where relevant) — purely additive.
• When false or absent, behavior is byte-for-byte identical to the plain-repo path, matching gittensor-wire.ts's existing documented contract: "a self-host instance with no gittensor affiliation has zero footprint from it."
• No new global kill-switch needed — reuse the existing LOOPOVER_EXPERIMENTAL_GITTENSOR + per-repo manifest opt-in gate as-is.

Deliverables

• Enrichment hook in sub-issue 2's tool gated by shouldEnableGittensorForRepo.
• Test coverage proving identical output shape/behavior when gittensor is disabled or absent.

Resources

• src/review/gittensor-wire.ts:22 (isGittensorPluginEnabled, shouldEnableGittensorForRepo, resolveManifestOnlyFeature)
• src/registry/sync.ts (gittensorEnabledRepoFullNames, registry data available when enrolled)

Boundaries

• Must never gate whether the planning tool runs at all — enrollment only changes input richness, never availability.
• No gittensor-specific hardcoding may leak into the non-enrolled code path.
• Depends on sub-issue 2 (the tool being enriched).

[linear-code]

JSO-5289