feat(deliberate): add haiku pre-sweep to design-review pipeline

Problem

The design-review pipeline (Phase 0 → Phase 1 sonnet tracers → Phase 2 opus classification) dispatches sonnet tracers without any signal density map. Sonnet tracers explore concerns uniformly, with no attention anchoring on areas that are more likely to have issues.

The PR review pipeline already solves this: run_haiku_sweep produces fast signals → signal density drives chunk sizing → sonnet reviewers receive signals as attention anchors. Design-review should have an equivalent phase, but it was lost when the pipeline went from planning to implementation without a design pass.

Context

• The adversarial-elicitation skill already has 8 haiku scouts for design documents (--sweep flag): entity-API alignment, field consistency, requirement-endpoint coverage, auth coherence, state machine completeness, formula consistency, integration spec completeness, cross-doc consistency.
• PR review uses run_haiku_sweep MCP tool → compute_review_chunks for signal-driven topology → signals passed as attention anchors to pr-code-reviewer agents.
• Design-review's Phase 0 already extracts custom concerns/changes/interfaces per document.

Open Design Questions

1. Reuse run_haiku_sweep or new tool?

run_haiku_sweep operates on git diffs categorized as source/peripheral/infra/test. Design-review operates on design documents with a different structure (sections, claims, interfaces). Options:

• A: Adapt run_haiku_sweep to accept design documents (mode parameter)
• B: Extract the adversarial-elicitation scout pattern into a new run_design_sweep MCP tool
• C: New tool purpose-built for design-review tracing

2. Concern list source

• A: Use the 8 hardcoded design-mode concerns from adversarial-elicitation (simpler, generic)
• B: Use Phase 0's extracted concerns/changes/interfaces (more targeted, custom per document)
• C: Hybrid — hardcoded generic concerns + Phase 0 seed patterns injected into scouts

3. Phase ordering

• A: Haiku runs BEFORE Phase 0 → generic concerns, but signals inform concern extraction
• B: Haiku runs AFTER Phase 0 → uses extracted concerns as scout targets, but adds latency
• C: Haiku runs in parallel with Phase 0 (generic concerns only, no dependency)

4. Signal-to-tracer routing

• A: ALL haiku signals passed to ALL sonnet tracers (simple, slightly noisy)
• B: Signals filtered per tracer by concern/change/interface category (requires mapping logic)
• C: Signals grouped by design section, tracers get sections relevant to their seed files

5. Signal consumption model

In PR review, signals drive chunk sizing (high-signal = smaller chunks for deeper review). Design-review tracers are 1:1 with concerns, not chunk-based. How should signal density affect tracer behavior?

• A: Attention anchors only — tracers receive signals as "look harder here" hints (like pr-code-reviewer)
• B: Density-weighted turn budget — high-signal tracers get more maxTurns
• C: Priority ordering — high-signal tracers spawned first, low-signal tracers skipped if budget exceeded

6. Token budget

8 haiku scouts at ~3k tokens each = ~24k additional. Current pipeline is 13 sonnet tracers. Is the cost justified, or should design-review use fewer scouts (e.g., 4 highest-value concerns)?

Acceptance Criteria

• [ ] Design document created and reviewed before implementation
• [ ] Haiku pre-sweep phase added to design-review SKILL.md
• [ ] Sonnet tracers receive haiku signals as attention anchors
• [ ] Signal density visible in tracer-health.yaml output
• [ ] No regression in existing design-review pipeline behavior