test(v4): pin the lazy safeParse error's stack behavior (#6548)

* test(v4): pin the lazy safeParse error's stack behavior

Deferring construction moves it to the read, so the worry is that the reader's frames end up on the error instead of the parser's. They do not: newError() suppresses the capture inside the constructor, whenever that runs. Two cases were unpinned — a read a macrotask later and twenty frames deeper, and a stackTraceLimit changed between the parse and the read, which a parse-time capture would clobber on restore.

Both assertions were checked against a control: a plain Error built at the same depth carries the readDeep frames, so passing them is evidence rather than a vacuous green.

* test(v4): move the late-read control into the test itself

The control was run alongside the test rather than inside it, so a future change to stack formatting could make the assertions pass while proving nothing. Building a plain Error at the same depth in the same test makes it self-validating: the control asserts the frames are there, the subject asserts they are not.