Task lifecycle: stamp meta.taskId on held sends; clarification state + workBotId (remainder of #111, needs #55) #111

Non-blocking findings from the independent review of #110 (PASS at a76230c). Collect them before #55/#57 build on the state machine.

1. Hold linkage is per-Bot, not per-task (Low). taskHeld/taskDecided match by ownerBotId, so one held send blocks all of that Bot's working tasks with the same approvalId — and rejecting one card cancels all of them. Fine single-human, wrong once Bots work several tasks. Fix shape: link holds to tasks explicitly (e.g. the send carries a taskId in meta via the [Team] Persist a minimal collaboration task lifecycle #54 work-start wiring, or match on the round the task started).
2. Prune window can drop a result-ready task (Info). ACTIVE excludes result-ready, so a task awaiting requester acceptance is evicted once terminal records exceed 200. Add result-ready to the protected set (its whole point is waiting for the requester).
3. Authz prefix over-allow (Info). ep.startsWith('task-') auto-ALLOWs any future task-* endpoint for any signed-in actor. Replace with an explicit set when the next task endpoint lands.
4. Clarification state + workBotId are neither implemented nor deferred (Info). The issue lists clarification (asks the requester) in scope; the specialist link workBotId is declared but never assigned. Either land them with [Team] Recover task handoffs without duplicate work #55's exchange wiring (a clarifying question is a request exchange; the specialist is the reply's sender) or split a dedicated issue.
5. Restart test assertion was weak (void-ed final move) — strengthened in the follow-up commit to this issue's PR; noting here for the record.

Plan update (2026-10-16, team mode via groups): No separate team-mode subsystem is needed; groups with per-Bot grants cover it. The remainder of this issue (items 1 and 4) is split across the ordered plan on #51 rather than waiting on #55.

• workBotId: effort S, in step 1 (Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149). Assign it on task-start, or on the first role:'request' exchange from ownerBotId to a specialist that carries meta.taskId (hooks.js run() / tasks.js, add rt.taskDelegated(msg)); ofSender() already matches it. This also gives per-task hold linkage (item 1). Test: a specialist hold blocks only that task.
• Clarification: effort M, in step 2. Add a clarifying state (working -> clarifying -> working, plus cancel and fail) with task.question = {text, askedAt}. A new task-bound Bot tool task_ask(taskId, question) posts a card in the origin room or session; the requester's answer goes through answer-question and resumes the task. Files: tasks.js, tools.js, authz.js (allow-list; use an explicit set, see item 3), client/cells.js. Includes the room task card.

Related: #54, #110, #55, #57.