Consume Hypatia route metadata with active blast-radius management

[hyperpolymath]

Failure type

The fleet receives Hypatia findings, but actuation is not tied to structured route/safety metadata or active blast-radius management.

Evidence

echidna has large Hypatia alert buckets, including workflow hygiene, language migration, structural drift, and code-safety findings. Some are mechanical PR candidates, some require proof review, and some are scanner/reporting hygiene. Treating them all as generic findings means the fleet either does nothing useful or risks acting on shallow labels.

Expected behavior

gitbot-fleet should consume Hypatia's structured metadata and decide:

• bot route: rhodibot, echidnabot, panicbot, sustainabot, or executor;
• action mode: report-only, PR-only, proof/review, canary, or blocked;
• confidence tier and recipe provenance;
• whether the finding is lifecycle hygiene that may need farm orchestration instead of a bot-local action.

Active-management requirements

• Dry-run is default for newly introduced rules or routes.
• Canary repos are required before estate-wide execution.
• Per-rule and per-repo concurrency limits are enforced.
• Action dedupe prevents repeated PRs/comments for the same stable finding.
• Quarantine/kill switch can stop a rule, recipe, or bot route.
• Failures and false positives lower confidence automatically.

Acceptance criteria

• Fleet ingestion reads hypatia.finding_id, category, class, route, and dispatch safety.
• Unknown categories route to report-only.
• Auto-execution is impossible without explicit confidence, recipe, and gate approval.
• A bad Hypatia rule tweak cannot fan out as mass repository changes.