lib,src: preserve domexception in v8 serialize/deserialize

[efekrskl]

Closes #53225

Not sure whether v8.serialize()/deserialize() should preserve DOMException, but I took a shot since structuredClone() already does. This should treat DOMExceptions as a host object and use a escape hatch for serializing them on our end.

[codecov]

Codecov Report

❌ Patch coverage is 88.37209% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.72%. Comparing base (4f13746) to head (b033bf4).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_serdes.cc	72.22%	2 Missing and 3 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #61856   +/-   ##
=======================================
  Coverage   89.72%   89.72%           
=======================================
  Files         675      675           
  Lines      204806   204849   +43     
  Branches    39355    39363    +8     
=======================================
+ Hits       183761   183807   +46     
- Misses      13330    13331    +1     
+ Partials     7715     7711    -4     

Files with missing lines	Coverage Δ
lib/v8.js	99.08% <100.00%> (+0.04%)	⬆️
src/node_serdes.cc	68.75% <72.22%> (-0.13%)	⬇️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[addaleax]

No particularly strong feelings, but I'll point out that the ability to (de)serialize custom objects is part of why Serializer and Deserializer are exposed as abstract classes

[addaleax]

DOMException is a per-context concept in Node.js, so I don't think instanceof is a reliable brand check (as usual in JS)

[efekrskl]

Would it make sense to check the symbols instead?

Something like:

const cloneSymbol = abView?.[messaging_clone_symbol];
if (typeof cloneSymbol === 'function') {
// ...call
}

[addaleax]

Yeah, something like that would probably be a better brand check.

I'm not sure how well messaging_clone_symbol works, it's going to cover other cases than just DOMException – and that's not necessarily a bad thing, but potentially quite a bit more effort to implement properly – especially when structuredClone is already dealing with it just fine

[efekrskl]

No particularly strong feelings, but I'll point out that the ability to (de)serialize custom objects is part of why Serializer and Deserializer are exposed as abstract classes

Thanks for the input! I mostly just opened this to see what folks think and if this would make sense to support by default.

If custom serializers make more sense, that's fine. I'm not strongly attached to it