protocol: explicit terminal closeout marker + room archive/reopen lifecycle (follow-up to #47)

[mostlydev]

Problem

#47 ships the documentation contract for terminal closeout (the three post-turn branches — active / passive / complete — plus the completion-evidence checklist and worked examples). It deliberately does not add a protocol-level terminal marker this release.

Reason (decided during #47, see docs/plans/2026-06-15-coordination-clarity-45-48-53.md): a room-closing tt release --complete / tt close that sets state="closed" is unsafe under the current model. path_rooms has UNIQUE (canonical_path) and joinPath returns the existing same-path room even when closed, so closing the canonical room would strand it with no archive/reopen path.

Required behavior (future)

Design and add an explicit, distinguishable terminal marker so two harnesses can record "shared task complete" in the protocol (not just in prose), and a room can be cleanly reopened for a new task:

• A terminal action (e.g. tt release --complete, tt close) that is clearly distinct from an ordinary release/pass (distinct event type or reason).
• A defined room lifecycle for completed rooms: archive vs. closed-but-reopenable, and how a subsequent tt join on the same canonical_path behaves (reopen? new room? explicit --reopen?).
• tt wait semantics on a completed room (does it return closed, and how does a harness restart a new shared task).
• Tests for: terminal marker emitted and distinguishable; reopen path; wait returns the terminal signal; no stranded canonical room.

Acceptance criteria

• An explicit terminal marker exists and is distinguishable from release/pass.
• Completing a task and then starting a new one in the same repo works without manual DB surgery.
• Regression coverage for the close → reopen lifecycle.

Follow-up to #47.