fix: mermaid fence queue matches by body — misalignment degrades to verbatim (INV-29 hardening)

Code review of 705de31's mermaid-diff wiring: buildMermaidQueue's overrides
were consumed positionally per rendered mermaid fence, so a fence the queue
didn't know about (a pending proposal's optimistic apply inserting a whole
new mermaid block, or annotateSource's committed-deletion reinsert) shifted
every later override by one and substituted the wrong diagram's augmented
source instead of the documented verbatim fallback. Queue entries now carry
{curBody, source} and are matched to fences by body (first unconsumed match,
scanning forward) so a non-matching fence renders verbatim without consuming
anything and a later matching fence still gets its augmentation. Also resets
the per-render consumed state in the renderer.render wrapper, since VS Code
can call md.parse()/renderer.render() separately and replay cached tokens
without a fresh parse.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

test/previewAnnotations.test.ts

@@ -131,4 +131,49 @@ describe("intra-diagram mermaid diff in the built-in preview (plan T7 §2.6, INV
     expect(html).not.toContain("cw-mermaid-legend");
     expect(html).toContain('class="language-js"');
   });
+
+  // Code-review hardening (705de31 follow-up): the queue used to be consumed
+  // POSITIONALLY per mermaid fence encountered, so a fence the queue doesn't
+  // know about (e.g. a pending proposal's optimistic apply, F12/INV-48,
+  // inserting a whole new mermaid fence ABOVE a changed one) shifted every
+  // later fence's override by one, substituting the wrong diagram's augmented
+  // source into the wrong fence instead of the documented verbatim fallback.
+  // The fix matches queue entries to fences by BODY: a fence with no matching
+  // entry renders verbatim without consuming anything, so a later matching
+  // fence still finds its own entry.
+  it("misalignment: an extra proposal-inserted mermaid fence above a changed one renders verbatim, and the changed fence still gets its own augmentation", () => {
+    const extraFence = "```mermaid\nsequenceDiagram\n  A->>B: hi\n```\n";
+    const src = extraFence + "\n" + flowchartAfter;
+    const html = render(src, {
+      ...base,
+      baselineText: flowchartBefore,
+      spans: [],
+      proposals: [{ id: "p1", anchorStart: 0, anchorEnd: extraFence.length, replaced: "", replacement: extraFence }],
+    });
+    const fences = html.split('<pre class="mermaid"').slice(1); // one chunk per fence, document order
+    expect(fences).toHaveLength(2);
+    // the extra fence has no matching queue entry: verbatim, no wrong-diagram substitution
+    expect(fences[0]).toContain("sequenceDiagram");
+    expect(fences[0]).not.toContain("cwAdded");
+    // the changed fence still finds its own augmentation despite the extra fence ahead of it in document order
+    expect(fences[1]).toContain("classDef cwAdded");
+    expect(fences[1]).toMatch(/class\s+c\s+cwAdded/);
+    expect((html.match(/cw-mermaid-legend/g) ?? []).length).toBe(1); // legend only on the augmented fence
+  });
+
+  // Body-match must not collapse two changed fences that happen to render the
+  // SAME current diagram into a single queue entry — each occurrence gets its
+  // own independent augmentation (consume-first-match, not a body->entry map).
+  it("two identical-body changed mermaid fences each get their own augmentation", () => {
+    const baselineText = flowchartBefore + "\n" + flowchartBefore;
+    const src = flowchartAfter + "\n" + flowchartAfter;
+    const html = render(src, { ...base, baselineText, spans: [] });
+    const fences = html.split('<pre class="mermaid"').slice(1);
+    expect(fences).toHaveLength(2);
+    for (const f of fences) {
+      expect(f).toContain("classDef cwAdded");
+      expect(f).toMatch(/class\s+c\s+cwAdded/);
+    }
+    expect((html.match(/cw-mermaid-legend/g) ?? []).length).toBe(2);
+  });
 });