Group turns: compress/load room context; progress from board not chat ping-pong #1203

Problem

交付组 (and similar multi-Bot groups) burn tokens because (1) every room turn reloads a large standing prompt + long chat lines, and (2) Bots narrate CI/merge progress in the room so the next speaker re-reads essays instead of looking at the task board.

Owner ask (2026-10-26): start from context compression and loading, then stop passing progress back and forth in chat — progress should come from the 看板 / track_tasks board.

Measured on prod tip 604ffa3a, room session-e9b2bc34-… (last 50 of 60): ~37k chars, avg ~750/msg, 1 human line; after @Chief 继续推进 → 8 bot msgs / 5.5k chars of status. Notice (~2k) is injected every call via standingText; history is message-count capped only (ROOM_FIRST_LOOK=12, ROOM_DELTA_MAX=24, no token budget). Related research: #796.

Desired behavior

1. Context compress / load (host)
   • Room history into the model should prefer a compact form: char/token budget (not only N messages), summarize or drop long status-shaped lines when building roomPrompt / unseenLines.
   • Standing group section stays cache-friendly; avoid stuffing progress essays into the turn cue.
   • Optional: when loading earlier context, prefer board snapshot + short recent lines over full CI narratives.
2. Progress from the board, not chat
   • Group turns that need status should read track_tasks / board state (already the source of truth) instead of re-asking peers in-room.
   • Prompt/rules for role: room / group cues: do not post PASS→enqueue→merge_group→main SHA novels; one-line handoff or [PASS] when the board already shows it.
   • Align with task-lead / taskDrive (Group kanban: one task lead assigns, and that Bot starts the card without a nudge #1182/Let one task lead assign group cards and start the assignee in the group #1185): wakes carry the task, board updates are the progress channel.

Out of scope (follow-ups)

• Rewriting a specific group’s notice text on prod (ops).
• Full TEAM_RULES slim for all private chats (can be a later PR).

Acceptance

• Focused tests: room prompt under a char/token budget; long status lines do not dominate FIRST_LOOK; a group turn that needs progress is steered to the board (or board text is injected compactly) rather than requiring peer status dumps.
• TZ=UTC npm run verify green; arch-docs updated if host/client docs change.
• Tip on current main; Birfy Reviewer PASS + Attestation before merge queue.

Evidence

Analysis: owner chat + dump of last 50 lines (seq 3003–3052). Hypothesis only: cheapest wins are budgeted roomPrompt + board-sourced progress cue + silence on status-for-someone-else — verify in code before locking design.