feat(registration): broaden registration readiness and config signals

[Khaostica]

Summary

Completes #38 by turning the repo-owner registration-readiness and Gittensor config recommendation into pure, unit-tested signal builders, and broadening the readiness report to evaluate every dimension the issue requires.

Output stays advisory and private/API-first: no public GitHub output, no wallet/hotkey/score exposure.

What changed

• Added src/signals/registration-readiness.ts with two pure builders:
  • buildRegistrationReadiness() — direct-PR readiness, issue-discovery readiness, label policy, maintainer-cut readiness, test-gate health, queue health, contribution docs, and GitHub App behavior (install state, quiet-by-default, missing permission/event warnings).
  • buildGittensorConfigRecommendation() — initial config recommendation with issueDiscoveryShare, label multipliers, maintainerCut, linked-issue policy, explicit tradeoffs, reasons, and warnings.
• Reworked GET /v1/repos/:owner/:repo/registration-readiness and .../gittensor-config-recommendation to delegate to the pure builders, and loaded installation health so the readiness report can describe real GitHub App behavior.
• Maintainer economics (maintainerCut) stay separated from miner rewards, and direct-PR-first stays the default unless issue-discovery intake is explicitly ready.
• Extended the RegistrationReadiness and GittensorConfigRecommendation OpenAPI schemas with the new fields.
• Added test/unit/registration-readiness.test.ts covering the required scenarios: ready repo, not-ready repo, issue-discovery-disabled recommendation, maintainer-cut readiness, missing-labels / missing-docs / missing-test-gate warnings, GitHub App permission/event warnings, lane variants, and a forbidden-public-language invariant.

Why

Issue #38 needs Gittensory to explain whether a repo is ready to attract Gittensor miner work and to recommend a safe initial config with tradeoffs. The previous inline logic (from the registration polish gate) did not evaluate test-gate or queue health, did not describe GitHub App behavior, and was only exercised through integration tests. Extracting tested builders closes those gaps and makes the signal verifiable.

Validation

• npx tsc --noEmit (typecheck) — passes
• npx vitest run test/unit/registration-readiness.test.ts test/integration/api.test.ts test/unit/openapi.test.ts — 26 passed
• npm run docs:check — passes
• New builder coverage: 100% statements/functions/lines, 96.55% branches (above the 95% gate)
• The full npm run test:ci gate runs on CI. (Locally on Windows, the mcp-cli / local-branch suites fail with a libuv child-process assertion that reproduces identically on the unmodified base branch — environment-only, unrelated to this change.)

Safety

• Backend-only change
• No secrets, wallet details, raw trust scores, or private rankings exposed; report is private/API-first and covered by a forbidden-language test
• Public text avoids compensation-seeking or optimization-tactic language
• OpenAPI schemas updated to match behavior
• No changelog changes (not a release PR)

Closes #38

[JSONbored]

@Khaostica this needs policy corrections before merge.

Required:

• Resolve the conflict in src/api/routes.ts.
• Do not treat disabled check runs as a registration-readiness warning; Gittensory intentionally defaults public checks off.
• Fix config math: do not subtract issueDiscoveryShare from emissionShare; emissions are assigned externally and issue-discovery share is repo config semantics.
• For Gittensory-specific recommendations, keep direct-PR-first posture and support the intended 30% maintainer cut when readiness is met.

[JSONbored]

@Khaostica The feature direction is still reasonable, and CI is green, but this cannot be merged in its current state.

A few notes:

• Broadening registration readiness and config signals is useful, especially if the route stays aligned with the current API/OpenAPI structure.
• The branch is currently conflicted with src/api/routes.ts.
• Because current main has moved substantially in the app/API surfaces, I do not want to approve the old route shape through a conflict. The conflict needs to be resolved first so the reviewed code matches what would actually land.

Required changes:

• Rebase onto current main and resolve the src/api/routes.ts conflict.
• Confirm the registration-readiness response still matches the current API and OpenAPI conventions.
• Re-run validation after the rebase.

Expected validation:

• npm run typecheck
• npm run test:coverage

[JSONbored]

@Khaostica This is ready from my side. The registration-readiness logic is now centralized in registration-readiness, the API route is mostly response glue, and the tests cover direct/split/issue-discovery policy, disabled public surfaces, config quality, and readiness blockers. Current checks are green and the merge tree is clean.