stack serialisation matches the engine actually measured

Captures of three real browsers on one machine pin this precisely: for the same collector, the serialised stack begins with the error name and message under one engine, and with a frame written in name-at-location form under the other two. The difference is structural rather than verbal. One family prefixes a header line and indents every frame beneath it; the other emits frames directly with no header at all.

Each shape is a property of that engine's serialiser rather than of any individual error, which is what makes it a stable thing to check. Nothing in this audit asked the question before, and the three neighbouring rows each ask something genuinely different.

The realm-agreement row compares the error dialect ACROSS realms and deliberately names no engine — its own reasoning is that naming one would create a table that rots, and that an unfamiliar engine should simply agree with itself and pass. That is the right design for what it does, and it is exactly why that row cannot say whose dialect it is reading. The binding-layer row covers the wording of DOM exceptions, which is generated by a different codebase entirely.

This one covers the JavaScript engine's own stack serialisation: a third, independent surface, and the only one of the three that describes the shape of the output rather than its text. It is anchored on the measured engine — the oracle no user-agent edit, client-hint shim or debugging-protocol override reaches — so relabelling cannot satisfy it, and the discriminator is the presence of a header and the form of the frames rather than any list of strings.