refactor(stdlib)!: rename unsafe AztecAddress constructors to *Unsafe

[nchamo]

Why we are doing this

The synchronous AztecAddress constructors that build an address from a raw value (fromField, fromBigInt, fromNumber, fromString) do not check that the value is a valid address: the x-coordinate of a point on the Grumpkin curve. An invalid value is accepted silently and only fails much later, when a transaction is sent. This recently sent an AI agent down a long debugging detour after it used fromBigInt in a test.

Validating requires curve math that is only available asynchronously today, so making the constructors validate would force them to become async. Instead we make the missing validation explicit at the call site.

Our fix

Rename the four unchecked constructors with an Unsafe suffix and document them:

• fromField → fromFieldUnsafe
• fromBigInt → fromBigIntUnsafe
• fromNumber → fromNumberUnsafe
• fromString → fromStringUnsafe

Each now carries JSDoc that it does not check Grumpkin-curve validity, pointing to isValid() to validate and random() for valid test addresses. The serialization constructors fromBuffer/fromFields keep their names: they are the structural (de)serialization interface (BufferReader/FieldReader.readObject, the Zod schema) and read addresses from already-validated protocol data, but their docs now note they perform no validation either. No constructor was made async and no curve check was reimplemented in TypeScript.

Migration

- const address = AztecAddress.fromBigInt(123n);
+ const address = AztecAddress.fromBigIntUnsafe(123n);

Use AztecAddress.random() for valid test addresses and address.isValid() to check an untrusted value. A migration_notes.md entry documents this.

Fixes F-754

[nchamo]

Relevant changes here

[nchamo]

Relevant changes here

[benesjan]

Perfect. Thanks for tackling this Chamo!

Will just merge it as it's conflict prone