DOMException: canonicalize persistent name and message StringData

Parent: #473 Related: #666, #681

Problem

The DOMException constructor coerces optional message and name through toStringV, then stores those physical bytes in persistent exception state. With physical flat Latin-1 storage active, getters and inherited Error stringification can republish invalid canonical StringData, and a non-ASCII name can be compared or serialized from the wrong representation.

Scope

• Route DOMException message and name coercion through the representation-aware WTF-8 helper.
• Preserve message-before-name coercion order, exactly one coercion per supplied argument, constructor/new-target behavior, legacy code lookup, prototype/accessor attributes, exception identity, ASCII borrowing, storage ownership, and OOM propagation.
• Cover exact non-ASCII name/message getters and inherited stringification under canonical and physical flat-Latin-1 storage.

No-workaround rules

• No flat-storage disablement, eager global canonicalization, replacement characters, duplicate coercion, alternate exception type, hidden retry, or Test262 exclusion.
• No stack, queue, job, Promise, Worker, agent, or Map/Set iterator changes.

Acceptance

• Persistent DOMException name/message state contains canonical semantic WTF-8.
• Getters and inherited stringification preserve exact non-ASCII text.
• Message coerces once before name, with abrupt completion preserved.
• The witness passes with canonical storage and with flat_storage_active enabled, then the switch is restored and not landed.
• Focused Debug/ReleaseSafe/TSan, relevant nonzero Test262 accounting when present, and full units pass with exact inventory reported.

Landed fix(domexception): canonicalize stored StringData (#682) on main.

DOMException message and name now cross representation-aware WTF-8 boundaries before persistent storage. The canonical and physical flat Latin-1 witness verifies exact getters, inherited Error stringification, and one message coercion before one name coercion.

Evidence: focused Debug, ReleaseSafe, TSan, and physical flat-storage witnesses each 1/1; Test262 contains 0 DOMException Web API cases, so no corpus pass is claimed; full units 1775 passed, 1 skipped, 0 failed, 0 leaked across 1776 tests.