feat(chat): bound the reading measure — T1 of the typography plan - #71

Nothing constrained the transcript's line length. The twelve max-width rules in
chat.html are all cards, dialogs and the empty state; the message column had
none. That went unnoticed for as long as the chat only lived in a ~380px sidebar,
where the container did the bounding — opening it as an editor tab (#70) put the
same CSS at 900px and produced ~154-character lines.

Now: every direct child of #log shares one 680px column, centred, behind a
--prose-max custom property so T5 can hand it to a setting. Applied to every
child rather than just .msg, or the cards and the activity timeline drift wider
than the prose they sit between.

MEASURED, not estimated — and the measurement corrected the plan. The doc's first
draft said "~72ch, near 640-700px". Both halves were wrong:

  "0" (the ch unit)         8.13px
  real average prose char   5.86px

`ch` is 39% wider than actual text, so a 72ch cap yields ~100 characters, not 72;
and 72 REAL characters is a 422px column, narrower than the sidebar. The print
range of 45-75 does not transfer to a chat carrying identifiers and file paths.
680px is ~116 characters, down from 154, and still wide enough that a fenced
block does not wrap constantly. The doc now records the correction; a test
asserts the cap stays an absolute length so nobody reaches for `ch` again.

Rhythm (D3) is em-based and GATED to >=760px. T1's exit criterion is that a
narrow panel renders exactly as before, and that is verified rather than assumed:
computed styles at 520px against develop are identical across padding, gap,
paragraph and heading margins, line-height and font-size.

Rendered and measured at three widths:

  520px   column 496  ·  81 chars  ·  padding 12px  (identical to develop)
  900px   column 680  · 115 chars  ·  padding 24px
  1400px  column 680  · 115 chars  ·  does not grow

Two guards added to webviewCss, because this regression is invisible in a
sidebar: whoever refactors the log container will not see it break, a user with
the chat in an editor tab will. Verified non-vacuous five ways — remove the cap,
scope it to .msg only, switch to ch, drop the width gate, drop the centring:
14-15/17 each. 33 suites green.

Review found CHAT-TYPOGRAPHY.md contradicting itself in three places. One cause:
D1 was corrected after measuring, and the correction was never propagated.

  intro            "~130-character lines"  → ~154, the figure actually measured
  T1 exit          "~72 characters"        → ~116, the 680px cap D1 settled on
  risks            "no test guards this"   → closed by the guards in this PR

The 130 and the 72 were both written BEFORE the measurement that produced 680px;
the risk bullet was true when written and stopped being true in the same commit.

Rather than proofreading it again, the number is now pinned to the code: a test
reads `--prose-max` out of the stylesheet and asserts the doc names that exact
cap, and that no stray reference to the disproved 72-character target survives.
Prose drifts from code silently — this is the only claim in the doc that a test
can hold, so it holds it. Caught both directions: change the CSS without the doc
(15/18), the doc without the CSS (15/18), reintroduce the old figure (15/18).

The fourth comment (detachedHtml has no CSP) was written against this branch
before it was rebased, when it still carried #70's commits. extension.js is no
longer in this PR's diff, and the CSP + nonce landed in #70 as dc91502.

33 suites green.