Tabs crash with "Session ID … is already in use" citing their own freshly created id, after accepting a brief

## What happened

Two researcher tabs opened successfully, accepted their brief via `bench tell`, and then died without running a single step. Both with the same error, visible in `bench ls`:

```
send-flow-research crashed Error: Session ID 78319ac4-3f0c-4496-b3cf-57771965ec98 is already in use.
send-flow-research-2 crashed Error: Session ID 54a166eb-869f-403b-baff-11bf75402105 is already in use.
```

The session id in each message is the id that `bench new` had just printed for that tab moments earlier. So the id being reported as "already in use" is the tab's own, freshly minted id — nothing else could plausibly have been holding it.

## Sequence, as observed from the specialist's shell

1. `bench new send-flow-research --as researcher` → printed `78319ac4-3f0c-4496-b3cf-57771965ec98`, and the usual "It is waiting - tell it what to do".
2. `bench tell send-flow-research ""` → `bench: told send-flow-research.`
3. Some minutes later, `bench ls` showed it `crashed` with the message above. It had produced no output and written no files.
4. Opened a second tab, `send-flow-research-2` → `54a166eb-869f-403b-baff-11bf75402105`. Told it the same brief. It sat at `awaiting_dispatch` through six polls over sixty seconds, then later also showed `crashed` with its own id in the message.

## It is intermittent, not systemic

A third tab opened about an hour later (`tab-probe`) started fine, and four subsequent tabs — `home-fix`, `quote-delivered-research`, `amount-screen`, `delivered-screen` — all ran and reported normally. So whatever this is, it is not "tab creation is broken"; it is something that went wrong twice in succession and then stopped.

Both failures were in the same stretch of wall-clock time (roughly 11:16–11:30), which makes a transient daemon-state or id-registration race look more likely than anything to do with the tabs themselves.

## Why it matters more than the crash count suggests

From inside a specialist, a crashed tab is indistinguishable from a slow one until you run `bench ls` and read the row. Both of these accepted their brief without complaint — `bench tell` returned `bench: told send-flow-research.` in both cases — so the work looked dispatched. I reported to my developer that research was underway when in fact nothing was running, and only found out on the next turn.

Two things would each have helped independently:

- **Fail loudly at `bench tell`.** If the target session is dead, telling it should error rather than acknowledge.
- **Do not let a tab report a brief as accepted when it cannot act on it.**

## Environment

- bench `0.1.0`, at `dc20608`
- Linux 6.6.87.2-microsoft-standard-WSL2, node v24.17.0
- Project `/var/www/fulacx-enterprise`; parent specialist on `opus`

## What I could not check

I have no access to the daemon's logs, and `/api/sessions` returns `{"error":"unauthorized"}` to a specialist, so I could not inspect session state to see what else, if anything, held those ids. Everything above is what is observable from a specialist's own shell.

Trace the bench new, bench tell, and bench ls entry points alongside daemon session registration and dispatch; /api/sessions is unavailable to specialists. Reproduce the intermittent self-collision or dead-session case and add coverage for it. Done means bench tell does not acknowledge a session that cannot act, and freshly created sessions no longer crash with their own id.

Written by the indexing model from the issue text.