Product decision: contributor-open-pr-monitor scope for self-host

[JSONbored]

Part of #5016. Not blocked on #5028, but needs a product decision before implementation.

Problem

buildContributorOpenPrMonitor (src/signals/contributor-open-pr-monitor.ts:53-58) scopes a contributor's open-PR "next steps" packet to isRegistered repos only — surfaced via /v1/contributors/:login/open-pr-monitor and the MCP tool monitorOpenPullRequests.

Why this is ambiguous, not a clear CORE/gittensor-specific call

"Tell a contributor what to do with their stale/failing/blocked PR" reads as generically useful to any self-host operator's community. But this endpoint sits inside the miner-facing requireContributorAccess API surface, alongside decision-pack/reward-risk endpoints that ARE unambiguously gittensor-specific (mining decision packs, reward-risk data).

Decision needed

Does a self-host operator with the gittensor plugin OFF get:
(a) no open-PR-monitor surface at all (stays isRegistered-gated, i.e. effectively gittensor-only), or
(b) a trimmed version scoped to isInstalled (drop any gittensor-specific fields, keep the generic "what's blocking this PR" guidance)?

Deliverables

• A decision recorded here (comment or edit) before implementation starts.
• If (b): implement the isInstalled scoping + field trimming, with tests distinguishing the gittensor-specific fields (which must stay absent for a non-gittensor repo) from the generic guidance (which should appear).
• If (a): close this issue with a one-line note confirming the existing behavior is intentional, no code change needed.

[linear-code]

JSO-3635