Refactor TerminalReporter to enum-of-modes when 3rd render flag is added

[Zious11]

Trigger

Triggered by PR review of #5 — type-design analyst flagged that TerminalReporter has 2 public bool fields (`use_color`, `show_mitre_grouping`) and the construction-site count grows linearly with each new flag.

Background

Current shape (src/reporter/terminal.rs):
```rust
pub struct TerminalReporter {
pub use_color: bool,
pub show_mitre_grouping: bool,
}
```

Construction sites: src/main.rs (analyze + summary paths), tests/reporter_tests.rs (multiple). Adding a 3rd flag means editing every construction site again.

Why defer

Validated against external best-practice (Perplexity): "at 2 booleans, refactoring preemptively risks over-engineering — bool-parameter smell becomes acute around 3-4 parameters." The current 2-field design is appropriate for now.

Trigger condition for this issue

When a 3rd render flag is being added (e.g., `--mitre-links`, `--no-progress`, `--compact`), pause and evaluate one of:

1. Enum-of-modes for mutually-exclusive render variants:
   ```rust
   pub enum RenderMode { Flat, GroupedByTactic, /* ... */ }
   pub struct TerminalReporter {
   pub use_color: bool,
   pub render_mode: RenderMode,
   }
   ```
2. Builder pattern (`TerminalReporter::new(use_color).with_mitre_grouping(...).build()`).
3. Keep public-fields struct if the new flag is genuinely orthogonal to existing flags.

Acceptance criteria

• The chosen approach is documented in the PR that adds the 3rd flag.
• All existing construction sites are updated coherently.
• No invariant relationships between flags are encoded only in `main.rs` comments — they should be expressible in the type system.

Out of scope

• Doing the refactor before a 3rd flag exists. YAGNI.