fix: keep a multi-line item detail's shape on the widget and markdown surfaces

[silversurfer562]

A detail carrying more than one line — a diff hunk, a log excerpt — was corrupted on the way out of both rendering surfaces. Found by probing the zero-change triage encoding for hunk review: the round table asserted the encoding works; running it showed what it costs.

Answer layer untouched — no validator, fold, or answer-shape changes.

The two defects

Widget. The detail rendered as an inline <span> inside a flex row with no white-space rule, so HTML folded its newlines and leading indentation into single spaces — a diff arrived as one run-on line, on the rich surface.

Markdown. The detail was interpolated into the item's bullet line, so every line it started with - — every removed line of a diff — parsed as a new bullet, and a suggested suffix landed on the detail's last line instead of the bullet.

- **bound the retry loop** `high` → suggested: `apply`
      @@ -88,7 +88,9 @@ def retry(fn):
      -    while True:
      +    for _ in range(MAX_RETRIES):

The fix

One helper and one CSS rule rather than four per-construct patches:

• widget._detail_html(text, cls) — inline <span> when single-line, <div class="… ae-detail-block"> when not. Five call sites: triage, assumption_review, both progress renderers, confirm.
• One CSS_BASE rule — .ae-detail-block { flex-basis:100%; white-space:pre-wrap; …monospace; overflow-x:auto; }, plus flex-wrap:wrap on .ae-prog-row / .ae-gate-row.
• markdown_surface._detail_block / _item_row — a multi-line detail becomes an indented code block under the bullet, suffix left on the bullet. Applied to triage, assumption_review, and confirm consequences.

A single-line detail still renders as the same inline span / inline em-dash it always did — the common case is byte-identical.

Why indented and not fenced

A fence cannot survive the markdown surface: _defuse_fences breaks every three-backtick run in author text so the trailing reply skeleton keeps its boundaries (confirmation pass 2). My first attempt fenced the block and it rendered as visible backtick-plus-zero-width noise. An indented block needs no backticks at all.

For the same reason an author's own ```lang wrapper is now stripped rather than kept — defused, it could only ever render as noise. The answers skeleton is verified to still round-trip: form_to_markdown → markdown_to_answers → collect_form_response, zero problems.

Theme budget

FORM_THEME_CSS raised 10 KB → 12 KB (chair-ruled 2026-08-28) for the shared rule; a trim to fit under 10 KB was offered and declined. Now 10,263 B, 2,025 B headroom. Recorded in the theme docstring alongside the previous three raises — the cap remains a design decision, not a ratchet.

Also included

docs/reports/roundtable/q-forms-hunk-review-001.md — the round table that surfaced this. 3/3 for build nothing: hunk_review stays consumer-gated, the reuse target is triage (not assumption_review, whose fixed vocabulary is the construct), and the interim costs zero files. The stub carries the zero-change encoding table and three pre-recorded flip conditions.

Verification

• 824 passing (11 new regression tests, each naming its defect and thread)
• ruff check + ruff format clean
• All four constructs' real HTML inspected, not just asserted
• Both defects are pre-existing and construct-agnostic — any multi-line detail hit them; diffs just made them obvious

🤖 Generated with Claude Code