feat(sync): track upstream Gittensor registry and scoring drift

[JSONbored]

Parent roadmap: #82

Background

Gittensory depends on upstream Gittensor registry, scoring, and issue-discovery behavior. Upstream changes can make local scoreability projections stale even when Gittensory itself is healthy.

Goal

Create scheduled drift detection that compares Gittensory's latest snapshots against upstream Gittensor sources and records actionable drift reports.

Current Behavior

Scoring and registry snapshots refresh, but there is no explicit upstream-drift report that tells maintainers what changed and what Gittensory modules may need updates.

Desired Behavior

Operators can see upstream commit/source changes, affected scoring/registry fields, severity, and recommended follow-up work.

Implementation Requirements

• Fetch official API data and raw upstream fallback files.
• Record upstream commit/source metadata where available.
• Compare scoring constants, active scoring model signals, repo registry fields, issue-discovery rules, and language weights.
• Store drift snapshots with severity and affected area.
• Surface drift in readiness/admin outputs without blocking normal service health unless core signal truth is unsafe.

Public/Private Output Boundaries

Drift reports are operational signals. Public docs may mention that drift exists, but public GitHub PR comments must not include private scoreability or raw scoring internals.

Acceptance Criteria

• Drift is detected when upstream constants or registry fields change.
• No drift report is created for identical snapshots.
• Reports include source, timestamp, fingerprint, severity, and affected modules.
• API failures mark drift as unavailable rather than pretending data is current.

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

• Fixture with scoring model change.
• Fixture with registry hyperparameter change.
• API unavailable fallback.
• Deterministic fingerprint regression.
• Secret-safe audit output.