test(tui): mouse_selection_autocopies_on_release_without_ctrl_c is red on main (post #6228 copy-path landing)

## Observed (deterministic, in isolation)

```
cargo test -p codewhale-tui --lib --locked \
tui::ui::tests::mouse_selection_autocopies_on_release_without_ctrl_c -- --exact

=> FAILED, finished in 0.09s
panicked at crates/tui/src/tui/ui/tests.rs:4038:
markdown copy must not touch the legacy status sink
```

## Attribution (file history, not a bisect)

- The assertion comes from `0dc66e6166` (the #6156 landing; its own commit message says the test "FAILS without the fix ... proving it pins the new behavior").
- The behavior path it pins (`crates/tui/src/tui/mouse_ui.rs`) was last changed by `ba7e7fa99` (#6228 "fragment selections copy exact text, not whole cells"), which also edited this test file — followed by the clippy sweep `10443600d`.
- The current fleet/engine slices do not touch `mouse_ui.rs` or this test (verified: working-tree diff contains zero `mouse_selection` changes).

So the likely shape is: #6228 changed which selection path writes the receipt, and the #6156 status-sink assertion was not updated with it. A 10-minute bisect on `ba7e7fa99` by whoever owns #6228 settles it.

## Impact

Red on main; one of the pre-existing reds every lane run has to filter out. Small, but it keeps costing every reviewer the same triage.

Reported by the Codewhale night program; no fix attempted (peer-owned path).

Start by running the exact cargo test command for tui::ui::tests::mouse_selection_autocopies_on_release_without_ctrl_c. Read crates/tui/src/tui/ui/tests.rs around line 4038 and trace the selection path in crates/tui/src/tui/mouse_ui.rs, using ba7e7fa99 as the bisect point. Done means the test passes in isolation and no longer requires filtering as a known red on main.

Written by the indexing model from the issue text.