merge: integrate origin/main (406 commits) into live branch

Merge upstream's paired-room stabilization, dedicated message-runtime-loop,
outbound delivery refactor (ipc-outbound-delivery / deliverFormattedCanonicalMessage),
discord module split, dashboard rework, and migrations 015-018 into our branch.

Conflict policy: prefer upstream for the heavily-refactored paired-room /
message-runtime / db cluster (it supersedes our earlier loop band-aids), keep
only orthogonal unique fixes:
- codex bundled-JS launcher fix (codex-warmup.ts)
- slot-aligned Claude+Codex usage primer (usage-primer.ts) re-wired into index.ts
- MemoryHigh=3G cgroup bound, discord perms diagnostic, prompt docs
- progress null-race + silent-failure publish guards (message-turn-controller.ts)

Dropped (superseded by upstream or unwired): reviewer STEP_DONE/TASK_DONE loop
band-aids, router markdown-escape override, register tribunal-default+git-init,
restart-context rewindToSeq (unwired).

Verified: typecheck clean, build clean, vitest shows zero new regressions vs the
origin/main baseline (only pre-existing env-config failures remain).

prompts/owner-common-paired-room.md

@@ -17,6 +17,26 @@ Before accepting any proposal from the reviewer, run it through:
 
 Challenge the reviewer's reasoning. Point out logical gaps, over-engineering, scope drift. Agree when the work is genuinely correct.
 
+## Debugging discipline
+
+For bugs, outages, failed checks, or unexpected behavior:
+
+- Identify the root-cause before changing code; do not patch symptoms first
+- Ground the diagnosis in evidence: exact error/log, reproduction path, recent changes, or component-boundary data
+- State one hypothesis and verify it with the smallest targeted test or command
+- Example: fixing the failed session/route/classifier is root-cause work; only increasing retries or hiding errors is a symptom patch
+- If the same failed fix path repeats 3 times, name the stagnation pattern and recommend a new direction instead of stacking guesses
+
+## Durable work notes
+
+Use short Markdown notes when they materially help handoff or continuity across sessions.
+
+- Good fits: broad architecture choices, multi-step plans, long debugging evidence, or user-requested design notes
+- Bad fits: small hotfixes, routine review loops, transient status updates, or notes that only restate chat
+- Example good note: decision, tradeoff, evidence, and next step; bad note: pasted status transcript or obvious command list
+- Use an existing docs/plans location when present; ask before creating a new docs directory
+- Keep notes brief: goal, decisions, evidence, next steps, and exact file/command references
+
 ## Completion status
 
 **Start your first line** with one of these six statuses. This is required.