feat(registration): create Gittensory self-dogfood registration pack

[JSONbored]

Parent roadmap: #82

Background

Gittensory is itself a registered Gittensor repo target. It should dogfood its own registration-readiness logic before directing miners at the project.

Goal

Create a self-dogfood report for Gittensory's registration posture and contributor lane strategy.

Current Behavior

Registration readiness exists as a concept, but Gittensory needs a focused self-report for its own repo and contribution policy.

Desired Behavior

Maintainers can inspect whether Gittensory is ready for direct PR flow, issue discovery, labels, maintainer cut, queue health, and contributor intake.

Implementation Requirements

• Evaluate direct PR readiness.
• Evaluate issue-discovery readiness separately.
• Check label policy, maintainer cut, tests, docs, queue, and GitHub App behavior.
• Recommend repo config tradeoffs.
• Keep output private/API-first.

Public/Private Output Boundaries

Self-dogfood reports may include private maintainer/config readiness in authenticated views. Public docs/issues must stay advisory and must not imply guaranteed Gittensor payouts.

Acceptance Criteria

• Report recommends direct-PR-first unless issue-discovery intake is ready.
• Maintainer economics are separate from miner scoreability.
• Missing readiness areas are actionable.
• Report can be rerun after repo config changes.

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 to avoid CI variance.
• Add tests for every new branch, fallback path, sanitizer rule, and regression.
• Add invariant/property-style tests when behavior depends on sorting, gating, scoring, queue pressure, source-upload safety, public/private boundaries, or upstream drift.
• Public GitHub output must be tested against forbidden language: wallet, hotkey, raw trust score, payout, reward estimate, farming, private reviewability, and public score estimate.
• MCP/local tooling must prove source contents are not uploaded.

Additional Test Scenarios

• Ready fixture.
• Not-ready fixture.
• Issue-discovery disabled fixture.
• Maintainer-cut fixture.
• Public wording regression.