Ralph Loop 2026-03-16: Disabled Sleeve Diagnostics

Why

The prior candidate-review packet surfaced sleeve_disabled as a blocker, but it did not identify which sleeve family was causing the bottleneck. In the current live state that hid a useful operator fact: the top review candidate was blocked specifically by the disabled politics_midprice_reversal sleeve.

Change

1. Updated research/candidate_review.py to expose: - disabled_sleeve_candidate_count - top_review_candidate_disabled_sleeves - top_research_candidate_disabled_sleeves
2. Updated research/continuous_loop.py so candidate_review_done events carry the top disabled sleeve families by state.
3. Updated research/status.py and research/discord_status.py so operator summaries show disabled-sleeve concentration directly.
4. Documented the new packet fields in research/README.md.

Validation

1. pytest -q tests/test_candidate_review.py tests/test_continuous_loop.py tests/test_research_status.py - 19 passed in 0.34s
2. python3 research/candidate_review.py --db data/unicorn.db --recent-runs 6 --max-per-state 3 - disabled_sleeve_candidate_count: 1 - top_review_candidate_disabled_sleeves: politics_midprice_reversal=1
3. python3 main.py research-status - candidate review line now includes disabled_sleeves=1 and review_disabled_sleeves=politics_midprice_reversal=1
4. python3 main.py research-discord-status - Discord summary now includes the same disabled-sleeve bottleneck explicitly

Result

Ralph can now distinguish:

1. unmatched live rows with no semantic sleeve coverage
2. valid live rows that are bottlenecked only because a sleeve family is disabled

That keeps PRD 003 operator output focused on signal quality instead of generic blocker labels.