Phase 9 / Task 9.3: im-worker dynamic-device integration spec

[winrey]

Context

The im-worker is the path that turns a team9 message into a hive sendInput call, and along the way it builds the `team9Context` payload that ahand-integration relies on for `peerUserId` resolution. The full chain is currently only verified by today's E2E smoke (live deploy + bot DM).

Scope

Add `apps/server/apps/im-worker/src/post-broadcast/integration/ahand-dynamic-device.integration.spec.ts` driving the `pushToHiveBots` path with a mocked claw-hive-api endpoint and a real (or testcontainer'd) Postgres for bot lookup.

Scenarios from Phase 9 / Task 9.3 (§ 9.4.5 / § 9.4.8 im-worker matrix):

1. DM happy path: human sends a message in a direct channel containing one hive bot → `sendInput` fires once with the right `sessionId` and a `team9Context` whose `peerUserId == sender.id`, `scopeType == "dm"`.
2. Group @mention: same channel layout but a public channel; only @-mentioned bots receive `sendInput`. Non-mentioned bots get nothing.
3. Topic-session collapse: `channels.type == 'topic-session'` → location wire is `"dm"` (collapses with routine-session and direct).
4. Mentor flag: bot's `mentorId == sender.id` → `team9Context.isMentorDm == true`. Non-mentor sender → `false`.
5. Tracking auto-forward: thread reply where a tracking channel already exists for that root → forwarded to the tracking session id, not a new one.
6. Skip non-human-authored messages: bot-authored messages are dropped (no `sendInput` call).
7. Skip deep-research messages: messages flagged in metadata as deep-research are dropped.

Acceptance criteria

• All 7 scenarios pass via `pnpm --filter @team9/im-worker test:integration ahand-dynamic-device`
• Runtime < 60s in CI
• `ClawHiveService.sendInput` is mocked at the module level so the spec does not need a real hive-api running
• Reuses the testcontainer fixture from Phase 9 / Task 9.2 (remainder): testcontainer'd gateway e2e for ahand DB+Redis scenarios #73 (Task 9.2) where applicable

References

• Phase 9 / Task 9.3 in `docs/superpowers/plans/2026-04-22-ahand-integration-plan.md`
• `apps/server/apps/im-worker/src/post-broadcast/post-broadcast.service.ts:594-870` (the path under test)

[winrey]

Re: scenario 5 wording — investigated; the actual code is by-design (commit 28907d81 "create new tracking channel and session for each thread reply" deliberately reverted earlier session-reuse logic for "fresh context per interaction"). The misleading "auto-forward to the same agent session" comment was stale, leftover from before that commit. Fixed in 8157b1a0 along with the integration spec assertion.

The accurate description for scenario 5 in this issue should be:

Tracking auto-forward: thread reply where a tracking channel already exists for that root → bot triggers without @mention (gate predicate satisfied), and a fresh tracking channel + session is spawned for this reply (the existing one is not reused — see commit 28907d8).

Implementation closed by ba737e0 + 8157b1a; integration spec passes 8/8.