Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149

Proposed issue / PR title: feat(tasks): responsible-owner authority, FLYBOT-TASK envelope and workBotId.

Goal: step 1 of making team mode work on top of groups and per-Bot grants. There is no separate team-mode subsystem and no flag: docs/subsystems/team.md defines team mode as a documented gate, and the real gap is that the task layer (#54) is passive. Nothing drives tasks, only the requester can act on them, and a task exists on one host only. Analysis: team-via-groups.md. Parent: #51.

Scope:

• Add responsibleOwnerId to the task record (the owner of the responsible Bot, e.g. Bob).
• Split allowed task actions: the requester keeps accept-result and cancel; the responsible owner may claim, start, return and clarify (clarify transitions land in step 2). Replace the ep.startsWith('task-') allow with an explicit endpoint set (see Task lifecycle: stamp meta.taskId on held sends; clarification state + workBotId (remainder of #111, needs #55) #111 item 3). tasks must be visible to both parties.
• Add a FLYBOT-TASK envelope beside the FLYBOT-ROOM-SHARE / FLYBOT-FACE-HUMAN envelopes in plugins/social, so a task is visible to both homes. Mirrored state is data only, never authority: the receiving home still checks grants, membership and owner on every action.
• Assign workBotId on task-start, or on the first role:'request' exchange from ownerBotId to a specialist that carries meta.taskId (hooks.js run() / tasks.js, via rt.taskDelegated(msg)). This also fixes hold linkage per task (Task lifecycle: stamp meta.taskId on held sends; clarification state + workBotId (remainder of #111, needs #55) #111 item 1).
• Start emitting audit events from the existing seams (transition, hold / decide / release), so history is not lost before [Team] Add a human-readable authorization and task audit trail #57 lands.

Out of scope: clarification state and the Bot task tool (step 2), handoff recovery (#55), budgets (#56), audit read endpoint and UI (#57), the pilot harness (#58), any team-mode flag.

Dependencies: #54 (done), #111 (remainder), #51 (grants). Blocks steps 2-6 in the ordered plan on #51.

Acceptance and tests:

• responsibleOwnerId is set and persisted; the requester can accept-result and cancel; the responsible owner can claim, start and return; neither can perform the other's actions, and a third owner can do neither.
• tasks shows the task to both the requester and the responsible owner.
• A FLYBOT-TASK envelope mirrors task state to the other home; a forged or stale envelope grants no authority and cannot move a task.
• workBotId is assigned on task-start or the first tagged request; a specialist hold blocks only its own task, and rejecting one card does not cancel the Bot's other tasks.
• Audit events are emitted for transitions and hold decisions, with whitelisted fields only (no bodies or secrets).
• Existing core and plugin tests stay green.

Delivery

One focused implementation PR for this issue. This is planned work, not a claim of shipped multi-human support. Preserve the pristine upstream pin and generated patch/client boundaries. Keep team mode disabled until the documented authorization gates pass. Record exact tested head, executed checks, missing checks and independent review. No production credentials or live deployment are part of this issue.