Bug: Slack thread ownership transfer can leave broker and workers unable to post

[gugu91]

Problem

Slack/Pinet thread ownership transfer is still confusing or broken in recent broker-delegation flows.

Observed today:

• Broker transferred Slack thread 1779139556.450249 to workers via pinet action=send with transfer_thread_id multiple times.
• Workers still reported they could not post directly because they only had a thread timestamp without enough Slack channel/context, or Slack/Pinet reported that the thread was owned by another agent.
• Broker relay with slack_send back to the original thread also failed with: Thread 1779139556.450249 is already owned by another agent.
• Human-visible status had to move to side thread 1779139896.435149, which made coordination confusing.

Expected behavior

After a broker transfers a Slack thread to a worker, the worker should have enough channel/thread ownership context to post status directly in that Slack thread.

If transfer cannot be completed, or if ownership remains with another agent, the system should expose a clear state and recovery path instead of leaving the broker and worker unable to post in the original thread.

Repro / investigation notes

A likely repro path:

1. Receive a Slack-originated task in a broker-owned thread.
2. Delegate to worker A with pinet action=send args.transfer_thread_id=<slack thread_ts>.
3. Re-delegate or transfer the same Slack thread to worker B.
4. Have the worker attempt direct Slack/Pinet reply to the transferred thread.
5. Have the broker attempt relay to the original Slack thread after ownership has moved.

Check whether the receiving worker gets durable Slack channel + thread context, not only the Slack thread timestamp. Also verify that all transfer-related state changes agree:

• explicit Slack thread owner binding
• Pinet inbox/thread-affinity metadata
• unread row ownership
• any Slack context cache used by slack_send / Pinet delivery
• diagnostics and error messages when owner/context is missing

Related prior work: #696, #722, and possibly #744.

Acceptance criteria

• Explain the current ownership-transfer state machine and where it fails for the observed flow.
• Fix the transfer/reply path if feasible, including regression coverage.
• If a worker cannot receive enough Slack context to post, expose a clear diagnostic/recovery path.
• Preserve first-owner-wins behavior unless the broker explicitly transfers ownership.
• Do not expose Slack tokens, secret values, private prompt contents, or local secret paths in logs, issues, or tests.

[gugu91]

Root cause found and fix opened in #758.

Summary: transfer_thread_id updated broker DB ownership but the A2A transfer message only carried the Slack thread timestamp. Follower runtime partitions A2A messages away from normal Slack inbox sync, so workers never cached the Slack channel/source context required by slack_send/Pinet Slack delivery. Once ownership moved, broker relays then correctly failed with “already owned by another agent,” leaving no visible-thread reply path.

Fix in #758: broker enriches explicit transfer metadata with Slack source/channel, and followers sync that explicit transfer context into their local thread cache before delivering the A2A prompt. Non-Slack or missing-channel transfers remain rejected/ignored to preserve safe ownership semantics.

Validation: focused Vitest, pnpm lint, pnpm typecheck, pnpm test, and pre-push all passed.

[gugu91]

Coordination update: Crem Scraper’s original lane PR #757 is now open and covers the material root cause/fix. I compared it against my backup PR #758; #757 includes the same core transfer-context repair (Slack source/channel metadata + follower thread-state hydration) and adds visible slack_send/recovery guidance. I do not see a material gap to carry from #758, so I closed #758 as superseded by #757.