XERK-518 [Qwen L]: peer roster + cross-session messaging (SEND + RECEIVE)

[xerhab]

Summary

XERK-348 matched for the Qwen Code runtime — the dsh [L] (XERK-476) analogue. The peer ROSTER
was already runtime-independent (any running session lists, _launch_qwen already appends
PEERS_SYSTEM_PROMPT); this adds the MESSAGING, hub-routed both ways so the Claude-inbox
protocol and crossSessionInbound policy stay in one Python home.

The load-bearing difference from dsh: dsh is headless with a control socket, so its driver
pushes peer events over that socket. qwen is an interactive TUI with no control socket,
so both directions are file-rendezvous based and delivery to a qwen target is pane-based:

• SEND (qwen → peer): agent/qwen/peer_mcp.py registers send_message({to, message}) via
  MCP (turma-peer, the same mechanism turma-ask uses for AskUserQuestion, since qwen has
  neither native tool). The call writes a request file and returns immediately
  (fire-and-forget, mirroring Claude Code's own SendMessage). The hub resolves the roster name
  against this host's running sessions and dispatches per target runtime: claude via
  _post_to_inbox (sender = the qwen session's own name, no INBOX_PREFIX — indistinguishable
  from a native peer), dsh via its control socket, qwen via _type_into_pane.
• RECEIVE (native Claude peer → qwen): agent/qwen/peer_inbox.py forges a
  ~/.claude/sessions/<pid>.json record + binds cc-socks/<pid>.sock under its OWN live pid
  (required for Claude Code's SO_PEERCRED liveness check), run as a per-session background
  subprocess. Inbound is verified against the wire session_id, policy-checked
  (crossSessionInbound), then typed into the pane.
• Both directions are drained off the beat by a polling worker
  (_qwen_peer_worker_loop, QWEN_PEER_POLL_SEC=2s), per the XERK-395 beat-loop budget contract
  — a Claude inbox post or a dsh socket write both block on a 5s-class ack. The two directions
  are told apart purely by a recv- filename prefix; every file is consumed once read whether
  or not delivery succeeded (best-effort, matching Claude's own SendMessage).
• _dsh_peer_frame is widened to a shared _peer_frame (now used by both runtimes).
  QWEN_PEERS_ADDENDUM (twin of DSH_PEERS_ADDENDUM) corrects the peer directive for a runtime
  with neither SendMessage nor ListAgents.

Docs: .claude/rules/qwen-peer.md (new file — qwen.md had only ~200 chars of headroom under
its 40k ceiling, so this follows the repo's own split-by-path remedy rather than editing it,
same as qwen-migration.md/qwen-delegation.md).

QA

Full qa pass returned FAIL with three findings (one MEDIUM, two LOW), all fixed in a
follow-up commit and re-verified by a qa-delta pass driving the real fixed code (not just
reading the diff) — PASS, all three confirmed closed:

1. MEDIUM — restart-orphaned subprocess. The peer-inbox forger is a bare Popen, not
   tmux-hosted. turma-agent.service runs KillMode=process so tmux/ttyd/dsh survive a
   manager restart for resume_on_boot's adopt path to reattach to — but that left the forger
   alive too with no adopt path, leaking one more live process + bound socket + registry record
   per restart, forever. Fixed by mirroring the existing ttydPid/_kill_ttyd pattern: the pid
   is now persisted on the session record and reaped on both start and teardown when it's an
   orphan. QA-delta confirmed the orphan is actually killed (os.kill(pid, 0) →
   ProcessLookupError) and that the pid reaches ~/.turma/sessions.json the same way
   ttydPid does.
2. LOW — atomic-write race. peer_mcp.py's tmp filename wasn't dot-prefixed, so the hub's
   poller (which skips dotfiles specifically to avoid reading a request mid-write) could
   occasionally read-and-delete a file before peer_mcp.py's own os.replace ran, reporting a
   spurious "write failed" for an already-delivered message. QA-delta reproduced 7/500 failures
   pre-fix under an aggressive real-filesystem race and 0/500 post-fix.
3. LOW/cosmetic — stale dotfiles. A writer crashing mid-write left a dotfile forever;
   now swept once older than QWEN_PEER_POLL_SEC * 5, confirmed a fresh one survives one pass
   and a real write completes orders of magnitude under that threshold.

Full test suite: 2222 passed, one pre-existing failure unrelated to this branch
(test_qwen_guard.py::TestQwenGuardShimEndToEnd::test_replace_in_aws_is_denied — this host's
~/.aws is a symlink to a WSL mount and the guard's credential globs aren't realpath'd;
confirmed failing on clean HEAD before this branch existed).

Not independently verified end-to-end (host-proof only, the same footing every prior [Qwen *]
child shipped on): the RECEIVE leg's real delivery over Claude Code's private inbox-record
format, and the mcpServers key actually surfacing the tool to a real qwen model.
QWEN_ENABLED=False fleet-wide, so none of this is reachable in production yet.

Separately flagged (not in this PR)

While running the suite I hit a pre-existing, security-shaped bug unrelated to this change:
the qwen/dsh safety-guard shim realpaths a tool's target path but matches it against
non-realpath'd credential globs, so a symlinked credential-store directory (e.g. ~/.aws
on WSL) escapes the deny rule and a write is allowed. Confirmed on clean HEAD. I could not
file a Jira ticket for it this session (the Jira connector was down); flagging it here so it
isn't lost — happy to file it or open a fix PR on request.

Test plan

• python3 -m pytest tests/ — 2222 passed, 1 pre-existing unrelated failure
• qa full pass → FAIL → fixed → qa-delta → PASS (see above)
• Syntax-checked all touched files