spec-by6.3 Phase 5b: inline comments on proposals Past Stand

Close the propose->critique->revise loop: the owner comments on blocks of a proposed document, the agent reads the comments, replies, and pushes a revision. Anchors re-resolve against the new revision rather than being lost.

Design gate cleared 2026-07-24: DESIGN.md deferred the comment schema until the Phase 4 review UI existed. It exists, and three facts from it shape the work: the review page renders only changed blocks (web/diff.go:61); the read view uses a different block model (doc.Renderer/goldmark, web/handlers.go:437) from the review view (prosediff.Segment); no rendered block carries a DOM id.

ANCHOR MODEL (as DESIGN.md:793-808 specifies, implemented not revisited):
tuple = (doc_id, heading_path, block_ordinal, block_hash). Resolve against a
revision by block_hash first; fall back to heading_path + ordinal; when both
fail mark the comment OUTDATED rather than relocating it. heading_path is
deliberately NOT part of the hash, so renaming a section does not dirty every
block beneath it and orphan its comments at once. Anchor on doc_id, not path,
so comments survive renames.

ANCHOR STATE IS DERIVED, NOT STORED. A comment is not outdated in general, it
is outdated AT a revision, and a proposal branch moves under it. The DB stores
the tuple; resolution runs at read time against the revision being displayed.

SIDE: a comment anchors to the NEW side of a modified block (that is the text
under review) and to the OLD side of a pure deletion.

SCOPE DECISIONS (settled with owner 2026-07-24):
1. Surface: the review page, ALL blocks — not only changed ones. This changes
   the diff view rule: renderDocDiff currently skips ChangeEqual entirely, and
   must instead render unchanged blocks as commentable context. Comments on
   approved documents (the read view) stay out of scope: that needs prosediff
   segmentation of the read path plus a goldmark<->prosediff block mapping.
2. Merge gate: an unresolved comment suppresses POLICY AUTO-MERGE only. Manual
   approve still works — human judgement wins. Rationale: a comment means the
   owner engaged, so the proposal must not slip through unattended; but a stale
   comment must not be able to wedge a proposal.
3. Agents: read + reply + revise via spec_comment. Agents may NOT resolve —
   an agent marking its own critique resolved defeats the gate.

A comment survives a revision that reflows its paragraph (hash miss, heading-path+ordinal hit) and is reported as moved, not lost. A comment whose block is deleted is reported outdated, never relocated. An unresolved comment prevents policy auto-merge and does not prevent manual approve. An agent can read and reply to comments on its own proposal but cannot resolve one.