fix(errors): Properly assign properties on hardened ocap errors

[sirtimid]

closes #169

This PR addresses the issue where Ocap errors had their properties stack and cause assigned incorrectly after hardening, which went unnoticed in tests due to mocking of the harden function.

The properties stack and cause are now assigned before hardening the error.

The unmarshalErrorOptions function is introduced to properly unmarshal and assign the error options, ensuring that the properties are correctly handled during the unmarshaling process.

Refactored unmarshalError to ensure the correct unmarshaling of properties before hardening.

Custom error classes adjusted to utilize unmarshalErrorOptions when unmarshaling error instances.

The tests have been updated to remove the mocked harden function, ensuring that the properties are correctly assigned and the hardened objects behave as expected.

[sirtimid]

I know we’re already importing it via the setupFiles option in the Vitest config, but I’m explicitly importing it here for clarity. It doesn’t hurt, right? :)

[grypez]

If clarity is good here, would it not also be good in the other tests, too? :)

For my part I think this is a fine canary to sing about changes to vitest.config.ts and nothing need be changed. I just don't think it's a clarity issue, and we can reasonably expect reviewers and developers to be familiar with the contents of setupFiles in the package's vitest.config.ts.

[sirtimid]

You are not wrong :) I guess it's not needed.

[grypez]

Small invitations for discussion, but LGTM.

[grypez]

Suggested change

	const output: ErrorOptionsWithStack = { stack: marshaledError.stack ?? '' };
	const output: ErrorOptionsWithStack = { stack: marshaledError.stack };

The type you define allows stack to be undefined. Why do you prefer to default to the empty string?

[sirtimid]

Right, I wrote it better.

[grypez]

If clarity is good here, would it not also be good in the other tests, too? :)

For my part I think this is a fine canary to sing about changes to vitest.config.ts and nothing need be changed. I just don't think it's a clarity issue, and we can reasonably expect reviewers and developers to be familiar with the contents of setupFiles in the package's vitest.config.ts.