Approval binding (#52) follow-ups: pinning test, docs wording, loud invalidateFor, release TOCTOU #97

Non-blocking findings from the independent review of #94 (rounds 1–2, tips fe8eef2 → f87ed85). None blocks the merge; collected here so they are not lost.

1. Pinning test for the invalidation narrowing (should-fix first). Round 1→2 narrowed Chief-replacement invalidation to sender-side holds: a hold addressed to a replaced Chief stays pending and decidable. Correct per docs/subsystems/team.md (decision authority is the sender Bot's owner; target reach is re-judged by reach() at release), but no test pins it — the existing test holds with the demoted Chief as sender. Add: hold from another Bot to the Chief, replace the Chief, assert the hold is still pending and the owner can still decide it.

2. Docs wording (trivial). team.md (approval-binding section), plugin-runtime.md invariant 10 and the ds-bot-core.md row list "demoted Chief" among release()/staleReason causes; the code realizes it only via the eager setMain wrapper (hooks.js), not inside staleReason. Observable contract holds; reword to "invalidated eagerly on setMain".

3. invalidateFor(botIds, reason, field) fails silent (hooks.js ~327). An unexpected field value no-ops the whole sweep instead of throwing. Two call sites today; make an unknown value throw so a future call site cannot silently skip invalidation.

4. Pre-existing, in-flight release TOCTOU (outside the [Team] Preserve request provenance and owner-bound approvals #52 diff, note for [Team] Recover task handoffs without duplicate work #55/[Team] Bound agent loops and resource consumption #56). Between release()'s revalidation and dispatch(), a concurrent setMain/deleteBot invalidation skips the record (status already approved) and the send can go out on the old verdict. Bounded in-process window; ownerPolicy (reach()) re-runs at release, which covers the per-Bot-grant half. Natural home: the recovery/dedup work ([Team] Recover task handoffs without duplicate work #55) or budget/cancellation ([Team] Bound agent loops and resource consumption #56), whichever touches release first.

Related: #52, #94, #55, #56.