Fix duplicate IDs in general

[alexander-turner]

📑 Summary

When multiple Mermaid diagrams share a page, identical SVG element IDs (nodes, edges, edge labels, markers, task lines, sequence lifelines, etc.) collide across <svg> containers. This causes browsers to bind event handlers, arrow markers, and CSS selectors to the wrong elements. Such incorrect binding breaks click callbacks, makes arrowheads disappear, and corrupts styling.

This PR extends the namespacing approach introduced in #4825 (which scoped marker IDs per graph) to all internally generated SVG element IDs across every diagram type. Each ID is prefixed with its diagram's unique SVG container ID, guaranteeing no collisions regardless of how many diagrams appear on a page.

Related PRs:

• #5741 — Duplicated IDs for markers (still open; stale, and without test coverage; this PR should obsolete its changes)
• #6621 — Open PR addressing duplicate ID generation in fast multi-block renders (complementary; targets container IDs, not element IDs)
• #4825 — Merged PR that gave markers unique IDs per graph (our approach extends this pattern to all element types)

Related issues:

• #4346 — bindFunctions interactions only work on one diagram instance when multiple are on the same page
• #1318 — Duplicate IDs across diagrams have potential to break some diagrams
• #3267 — Generated SVG has static IDs which cause issues with multiple SVGs
• #3433 — revealjs + mermaidjs arrows missing on 4th+ diagram (same root cause)

📏 Design Decisions

Following the precedent set by #4825: that merged PR scoped marker IDs by prefixing them with the graph container ID. We apply the same namespacing strategy comprehensively — to node IDs, edge IDs, edge-label IDs, cluster IDs, task-line IDs, sequence lifeline/actor IDs, timeline section IDs, C4 element IDs, and journey task IDs.

Implementation approach:

• Added diagramId field + setDiagramId() to FlowDB and ClassDB; added to the DiagramDB interface in types.ts so any diagram DB can opt in
• Each v3-unified renderer calls setDiagramId(id) with the SVG container ID before layout
• lookUpDomId() in FlowDB/ClassDB returns ${diagramId}-${originalId}
• The generic rendering path (render.ts, createGraph.ts, edges.js, clusters.js) prefixes IDs for diagrams routed through the shared renderer
• Diagram-specific renderers (sequence, journey, timeline, gantt, C4, kanban) prefix IDs in their own svgDraw / renderer files
• diagramId resets on clear() to prevent state leakage
• Cypress E2E test (multi_diagram_unique_ids.spec.js) + unit tests (unique-dom-ids.spec.ts, multi-diagram-id-uniqueness.spec.ts) covering all diagram types and collision scenarios

Breaking changes

• Marker IDs (e.g. arrowhead, crosshead) are now prefixed with the diagram's SVG element ID. Custom CSS or JS using exact ID selectors like #arrowhead should use attribute-ending selectors like [id$="-arrowhead"] instead.
• The first 13 changed Argos snapshots should be accepted. Explanation: CSS selectors like #statediagram-barbEnd and #compositionStart were changed to [id$="-barbEnd"] and [id$="-compositionStart"]. The old selectors were dead code — since PR Give markers unique id's per graph mermaid-js/mermaid#4825, marker IDs have been in the format ${diagramId}_${type}-markerName, so the bare ID selectors like #statediagram-barbEnd never matched. The new attribute selectors correctly apply marker styles that were always intended but never worked.

📋 Tasks

Make sure you

• 📖 have read the contribution guidelines
• 💻 have added necessary unit/e2e tests.
• 📓 have added documentation. Make sure MERMAID_RELEASE_VERSION is used for all new features.
• 🦋 If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Note: shape rendering should have unit tests

The packages/mermaid/src/rendering-util/rendering-elements/shapes/ directory has essentially no unit tests. Shape functions are only exercised via E2E visual tests, which always go through the full render pipeline. This means subtle bugs in how shapes handle domId vs id can go undetected until visual regression catches them (as happened with erBox.ts in this PR).