fix: enforce dispatch routing to the matched specialist (0.50.0)

[Shahinyanm]

What

Dispatch routing now blocks a high-confidence match instead of quietly suggesting it. Sending work to general-purpose when a tp-* specialist covers it is the most expensive mistake available in a session, and until now nothing stopped it.

Why

Measured on the same question, twice:

dispatch	tokens
general-purpose	57,921
tp-run	18,677

3.1x — about 39k wasted per launch, most of it startup cost a general agent pays before doing any work.

The matcher was never broken. It named the correct specialist on five of seven real descriptions. The suggestion just never landed: it went out as permissionDecision=allow with the advice in the reason, and an allow is something the model may ignore. Over one measured session it did exactly that — ten of eleven dispatches went to general-purpose while the matcher was naming a specialist every time.

Reads are disciplined because a wasteful read comes back denied. Dispatches were not, because they came back allowed. That is the whole gap.

How

• Deny mode (the default) now hard-blocks a high-confidence match and names the agent to use. The dead && ctx.force clause that made this tier unreachable goes with it — A || B || (C && D && A) is just A || B.
• Matching reads the prompt as well as the description. Real descriptions are two or three words ("Reuse check") and score low; the prompt carries the task and takes the same dispatch to high. Without this the blocking tier would almost never fire.
• containsEscape reads the prompt too, so an escape written there still works now that the prompt can trigger a block.

Risk

This changes default behaviour: some dispatches that used to pass will now be refused with instructions. That is the intent, and the blast radius is bounded on four sides — low-confidence matches still only advise, escape phrases still pass, TOKEN_PILOT_MODE=advisory disables blocking entirely, and tp-* dispatches are never touched.

Verified on a built dist: general-purpose + "review these changes for duplication" comes back denied naming tp-pr-reviewer; the same call with "ad-hoc" comes back allowed. Full suite 1445 green.

Notes for reviewer

The v0.31.0 test asserting the old advise-only behaviour is updated, not deleted — the old expectation was deliberate, so the change is deliberate too, and the test now records why.

Worth a second opinion: the confidence bar for blocking is score ≥ 3 or a quoted trigger phrase. Set it lower and legitimate dispatches start getting refused; set it higher and this stops firing again. Three is what the measured descriptions clustered around, but it is a judgement call, not a derived number.