[parity] structuredClone: cycles lose reference identity, and non-cloneable values throw TypeError instead of DataCloneError #8232

Split out of #6766 after PR #8229. Not a perf_hooks bug — perf_hooks is just where the node-suite happens to pin it, because mark/measure detail is passed through structuredClone.

Two gaps in Perry's structured clone:

1. Cycles are not preserved. The clone succeeds (no throw, which is already correct — a cycle is cloneable) but the reference identity inside the copy is lost.

test-parity/node-suite/perf_hooks/mark/detail-circular:

const o: any = {}; o.self = o;
const mark = performance.mark("c", { detail: o });
mark.detail !== o          // node true,  perry true   ✅
mark.detail.self === mark.detail   // node true,  perry false  ❌

test-parity/node-suite/perf_hooks/measure/detail-clone-failures hits the same thing via performance.measure("cycle", { start: 0, duration: 1, detail: cycle }).

The fix is the standard one: a memo map from source object to its clone, consulted before cloning each reference, so a cycle resolves to the already-created copy.

2. A non-cloneable value throws the wrong error type. Node raises a DataCloneError DOMException; Perry raises a plain TypeError.

measure/detail-clone-failures:

node:   function: DataCloneError
perry:  function: TypeError

crates/perry-runtime/src/event_target.rs already has js_dom_exception_new(message, name) and maps "DataCloneError" to legacy code 25, so this is a matter of routing the existing throw through it.

Both cases are exercised by ./run_parity_tests.sh --suite node-suite --module perf_hooks, but the underlying behaviour is structuredClone's and affects every caller.