fix(chat): bound the media block by braces, and stop the comment copying the cap

Both review comments on #75 were right.

1. THE GATE LOOKUP WAS STILL ORDER-DEPENDENT

My earlier fix found the rhythm block by content instead of position, but still
terminated the slice with `indexOf('\n  }')`. The --shell-x gate is written on one line,
so it has no `\n  }` of its own — the search ran straight past it into the next multi-line
block. Measured: for a rule whose body is 27 characters, the old search returned 238, i.e.
it reached about nine times past the rule it was supposed to bound.

It happened to resolve correctly, because the swallowed span did not contain `#log {`. That
is luck of ordering, not correctness. Demonstrated by moving the one-liner gate to sit
directly before the rhythm gate: under the old mechanism the FIRST gate's slice then
contains `#log {`, so it selects the wrong gate and asserts against a span covering both —
silently. Under balanced braces the same reorder still resolves to the right gate and all
30 tests pass.

`blockAt()` matches braces, over a comment-stripped copy so a brace inside prose cannot
throw off the count.

2. THE STYLESHEET COMMENT KEPT ITS OWN COPY OF THE CAP

It still said 680px and "~116 characters" after the cap became 820. That is the third place
this number has drifted and the only one nothing was watching — the existing pin covers
CHAT-TYPOGRAPHY.md, not the stylesheet's own prose.

Not synced: the comment must not carry the number at all, so it points at `--prose-max`
instead. The two font measurements (8.13px per `ch`, 5.86px per average character) stay,
because those are facts about the typeface rather than a decision that can be revised.

Guards, each bypass-verified by reverting the fix:
  - the rhythm gate losing its padding, proving the block is located non-vacuously
  - the comment restating the current cap, and restating the OLD one (the reviewer's bug)
  - the comment no longer pointing at --prose-max
  - plus the reorder above, which the previous mechanism failed and this one survives

30 tests in webviewCss, 32 suites green.

Author: ndemianc

extensions/levelcode-ai/media/chat.html

@@ -72,12 +72,15 @@
      in this file are all cards, dialogs and the empty state. In a 380px sidebar the container bounded
      it, so it never looked wrong — but the chat can now open as an editor tab (AI: Open Chat in
      Editor), and at 900px the same CSS produced ~154-character lines.
-     Measured in the shipped font at 13px: the average prose character is 5.86px, so 680px is ~116
-     characters — a real improvement while staying wide enough that a fenced code block does not wrap
-     constantly. NOT expressed in `ch`: `0` is 8.13px here, 39% wider than average text, so a `ch` cap
-     silently overshoots by about a third.
+     The cap itself is `--prose-max`, declared on `body`, and is deliberately NOT restated here. This
+     comment carried its own copy of the number and said 680 for exactly as long as it took the cap to
+     become 820 — which is what a second copy of a value is always for. docs/CHAT-TYPOGRAPHY.md D1 has
+     how it was chosen; webviewCss.test.js fails if this comment starts quoting a length again.
+     NOT expressed in `ch`: `0` measures 8.13px against an average prose character of 5.86px, so a
+     `ch` cap silently overshoots by about a third. Those two figures stay because they are facts about
+     the typeface, not a decision that can be revised.
      Applied to EVERY direct child, not just .msg, so messages, cards and the activity timeline share
-     one column instead of drifting apart at width. Below 680px this is inert — which is why the
+     one column instead of drifting apart at width. Below the cap this is inert — which is why the
      sidebar is untouched. */
   #log > * { width: 100%; max-width: var(--prose-max); margin-inline: auto; box-sizing: border-box; }
   /* ---- per-response copy button (hover-reveal under a completed assistant message) ---- */

extensions/levelcode-ai/test/webviewCss.test.js

@@ -21,6 +21,30 @@ const path = require('path');
 const html = fs.readFileSync(path.join(__dirname, '..', 'media', 'chat.html'), 'utf8');
 const css = html.slice(html.indexOf('<style'), html.indexOf('</style>'));
 
+// Comment-stripped CSS, for anything that reasons about BLOCK STRUCTURE rather than text. A `{` inside
+// a comment would throw off brace matching, and the comments in this stylesheet are prose-heavy enough
+// that one will eventually contain a brace.
+const cssBlocks = css.replace(/\/\*[\s\S]*?\*\//g, '');
+
+/**
+ * The body of the `{ … }` block that opens at or after `from`, matched by BALANCED braces.
+ *
+ * Written because the obvious shortcut is wrong: searching for a literal closing brace (`\n  }`) only
+ * terminates rules that happen to be formatted across multiple lines. A one-line block — like
+ * `@media (…) { body { --shell-x: 24px; } }` — has no such terminator, so the search runs on into the
+ * NEXT block and quietly returns a slice spanning both. A test built on that asserts against whatever
+ * the file's rule order happens to put in reach.
+ */
+function blockAt(src, from) {
+	const open = src.indexOf('{', from);
+	if (open < 0) { return ''; }
+	let depth = 0;
+	for (let i = open; i < src.length; i++) {
+		if (src[i] === '{') { depth++; } else if (src[i] === '}') { depth--; if (!depth) { return src.slice(open + 1, i); } }
+	}
+	return '';   // unbalanced — the caller's assertion fails on the empty body, which is the honest result
+}
+
 let n = 0;
 function test(name, fn) { fn(); n++; console.log('  ok - ' + name); }
 
@@ -273,6 +297,26 @@ test('TRANSCRIPT: the prose column is bounded, and every child shares the one me
 		'the measure should be an absolute length, not `ch` — see CHAT-TYPOGRAPHY.md D1');
 });
 
+test('TRANSCRIPT: the stylesheet comment keeps no copy of the cap', () => {
+	// Review found the comment beside the rule still saying "680px" and "~116 characters" after the cap
+	// became 820 — the third place this number has drifted, and the only one no test was watching. The
+	// doc pin above covers CHAT-TYPOGRAPHY.md; nothing covered the stylesheet's own prose.
+	//
+	// The fix is not to sync it. A comment that restates a value will drift again the next time the
+	// value changes, so it must not carry the number at all — it points at `--prose-max` instead.
+	const block = /THE MEASURE[\s\S]*?\*\//.exec(css);
+	assert.ok(block, 'the THE MEASURE comment is gone — this guard covers nothing');
+	assert.match(block[0], /--prose-max/, 'the comment must point at the property rather than restate its value');
+
+	// 380px and 900px are VIEWPORT widths — facts about where the problem showed up, which cannot go
+	// stale. Any other length in here is a copy of a decision that can.
+	const VIEWPORTS = ['380px', '900px'];
+	const restated = (block[0].match(/\b\d{3,4}px\b/g) || []).filter((v) => !VIEWPORTS.includes(v));
+	assert.deepStrictEqual(restated, [],
+		'the measure comment quotes a length again — reference --prose-max instead, or it drifts the next '
+		+ 'time the cap moves: ' + restated.join(', '));
+});
+
 test('SHELL: the composer shares the transcript column instead of spanning the panel', () => {
 	// docs/CHAT-TYPOGRAPHY.md D9. T1 bounded the TRANSCRIPT and nothing else, so at editor width the
 	// input was a ~1580px box under an 820px conversation — the single thing that most made the panel
@@ -332,14 +376,20 @@ test('TRANSCRIPT: the looser rhythm is gated to reading width, so the sidebar is
 	// T1's exit criterion is that a narrow panel renders exactly as before — a user who upgrades and
 	// never opens the editor tab should see nothing move. Verified against develop's computed styles
 	// at 520px: padding, gap, paragraph and heading margins, line-height and font-size all identical.
-	// Located by CONTENT, not by position: there is now more than one `min-width: 760px` gate (D9 gates
-	// --shell-x on the same breakpoint), and an indexOf would silently grab whichever comes first in the
-	// file — passing or failing on rule ORDER rather than on the thing being asserted.
-	const gates = [...css.matchAll(/@media \(min-width: 760px\)/g)].map((m) => m.index);
+	// Located by CONTENT, not by position: there is more than one `min-width: 760px` gate (D9 gates
+	// --shell-x on the same breakpoint), so an indexOf would grab whichever comes first in the file and
+	// assert on rule ORDER rather than on the thing being checked.
+	//
+	// And located with BALANCED BRACES, not by searching for a literal `\n  }`. Review caught that: the
+	// --shell-x gate is written on one line, so it has no `\n  }` of its own and the search ran straight
+	// past it into the next multi-line block. It happened to resolve correctly here — the swallowed span
+	// did not contain `#log {` — but only because of where the rules currently sit. Move one rule and
+	// the slice silently spans two gates, which is the same order-dependence in a new disguise.
+	const gates = [...cssBlocks.matchAll(/@media \(min-width: 760px\)/g)].map((m) => m.index);
 	assert.ok(gates.length, 'the width gate is gone — the rhythm change would now hit the sidebar too');
-	const at = gates.find((i) => css.slice(i, css.indexOf('\n  }', i)).includes('#log {'));
+	const at = gates.find((i) => blockAt(cssBlocks, i).includes('#log {'));
 	assert.ok(at !== undefined, 'no min-width:760px gate contains the #log rhythm rules');
-	const block = css.slice(at, css.indexOf('\n  }', at));
+	const block = blockAt(cssBlocks, at);
 	assert.match(block, /#log \{[^}]*padding:/, 'the wider page margin belongs inside the gate');
 	assert.match(block, /margin-bottom:\s*1em/, 'prose spacing must be em-based so T2 scales it');
 	assert.match(block, /h1[\s\S]*margin:\s*1\.6em 0 \.55em/,