Doghouse: implement real CodeRabbit state modeling or trim the promise

[flyingrobots]

Follow-up to #4.

Why

Doghouse’s docs and domain model promise reviewer-specific state for CodeRabbit, including states like:

• actively reviewing
• cooled down and requestable
• rate-limited
• paused behind manual rearm controls

But the current runtime does not emit CODERABBIT_STATE blockers or events.
That leaves a docs/runtime mismatch in one of the product’s most differentiated promises.

Current behavior

Relevant files:

• doghouse/README.md
• doghouse/playbacks.md
• doghouse/flight-recorder-brief.md
• src/doghouse/core/domain/blocker.py
• src/doghouse/adapters/github/gh_cli_adapter.py

The enum and design docs talk about CodeRabbit-specific state, but the GitHub adapter currently only models:

• unresolved threads
• checks
• approval state
• merge conflicts

Desired outcome

Make the runtime and the docs agree.

Two acceptable resolutions:

1. Implement real CodeRabbit state detection for the currently detectable/actionable states.
2. Trim the docs/playbacks/product claims back to what Doghouse actually knows today.

Acceptance criteria

• No stale promise remains in the docs.
• If implemented, CODERABBIT_STATE is emitted through a tested runtime path.
• If not implemented yet, the docs explicitly stop claiming that Doghouse can distinguish cooldown / pause / manual rearm states today.
• The result stays subordinate to human review state instead of eclipsing it.