feat(control-panel): add repo owner registration workspace

[JSONbored]

Background

Repo owners need to know whether they are ready for Gittensor contributors before opening the floodgates. This should be a readiness workspace, not a raw metrics page.

Goal

Create a repo-owner workspace for registration readiness, direct-PR vs issue-discovery guidance, label policy, maintainer-cut readiness, queue health, test policy, and suggested Gittensor config.

Current Behavior

Gittensory has readiness and signal concepts, but repo owners do not yet have a focused workspace for contribution intake decisions.

Desired Behavior

A repo owner gets a clear readiness report with tradeoffs, risks, and recommended configuration choices.

Implementation Requirements

• Use repo intelligence, registration readiness, queue health, and policy snapshots as inputs.
• Separate direct-PR, issue-discovery, and maintainer-lane recommendations.
• Explain maintainer-cut tradeoffs without promising payouts.
• Include freshness and degraded-data warnings.
• Keep output advisory and private/API-first.

Public/Private Output Boundaries

Public GitHub output must never include wallets, hotkeys, payout/reward estimates, raw trust scores, public score estimates, private reviewability, private scoreability context, or farming language. Private API/MCP/control-panel surfaces may show authenticated scoreability, blockers, projections, and evidence, but must not claim guaranteed payout outcomes.

Acceptance Criteria

• Repo owner gets a readiness report, not raw Gittensor data.
• Recommendations explain tradeoffs.
• Maintainer-lane economics are separate from miner rewards.
• Output is advisory and private.
• Tests cover ready, not-ready, and stale data cases.

Testing Requirements

• npm run test:ci must pass.
• Global coverage must remain at or above 97% for lines, statements, functions, and branches.
• Aim for 98%+ branch coverage locally.
• Add tests for every new branch, fallback path, sanitizer rule, and regression.
• Add invariant/property-style tests when behavior depends on sorting, gating, scoring, source-upload safety, public/private boundaries, or telemetry privacy.
• MCP/local tooling must prove source contents are not uploaded when local metadata is involved.
• Public GitHub output must be tested against forbidden language: wallet, hotkey, raw trust score, payout, reward estimate, farming, private reviewability, and public score estimate.