Blocking: TS interfaces declare $formatVersion but Rust serde tag is $version -- breaks constructors and output types

All 5 shielded transition Rust enums (ShieldTransition, ShieldFromAssetLockTransition, ShieldedTransferTransition, ShieldedWithdrawalTransition, UnshieldTransition) use #[serde(tag = "$version")], but the TS Object/JSON interfaces in this delta were changed to $formatVersion.

Impact on constructors: The 4 constructors using serde_wasm_bindgen::from_value() require {"$version": "0", ...} as the serde discriminant. A JS caller following the TS types will pass {"$formatVersion": "0", ...} - deserialization fails with a missing-tag error.

Impact on output: toObject()/toJSON() serialize through serde and produce {"$version": "0", ...}, but the TS return types declare $formatVersion. TypeScript consumers accessing obj.$formatVersion will get undefined.

The rest of the codebase (Identity, DataContract, address-based transitions) already uses serde(tag = "$formatVersion"). The 5 shielded enums are inconsistent -- update the Rust serde tags in packages/rs-dpp/src/state_transition/state_transitions/shielded/*/mod.rs to serde(tag = "$formatVersion").

_{source: ['claude', 'codex']}

Suggestion: #[serde(default)] on all fields silently accepts missing required cryptographic fields

Every field in ShieldFromAssetLockTransitionSimpleFields has #[serde(default)], which means the constructor silently succeeds with empty vectors and zero values if the JS caller omits actions, proof, bindingSignature, etc. While anchor and binding_signature are validated for correct length downstream (32 and 64 bytes respectively), the other fields -- actions, proof, value_balance, signature -- will silently default to empty/zero.

This creates a confusing failure mode: instead of getting a clear "missing field" error at the WASM boundary, a JS caller omitting required fields gets a structurally valid but logically broken transition that will fail much later during validation.

Consider removing #[serde(default)] from fields that are truly required (actions, proof, binding_signature, signature), or at minimum adding explicit emptiness checks after deserialization.

_{source: ['claude', 'codex']}

Suggestion: Uint8Array::new(&n) polymorphic behavior may allocate attacker-chosen buffers

parse_nullifiers() calls Uint8Array::new(&n) on each array element. In JS, new Uint8Array(number) creates a new zero-filled buffer of that length. If a caller passes [4294967295] (a plain number instead of a Uint8Array), this would attempt to allocate a 4GB buffer.

The 32-byte length check on the next line catches this eventually, but only after the allocation completes. Consider using Uint8Array::new(&n.dyn_into::().map_err(...)?) or checking n.is_instance_of::() first to reject non-Uint8Array inputs early.

_{source: ['claude', 'codex']}

Nitpick: outputAddress typed as bare object -- inconsistent with rest of PR

All other complex types in this iteration received properly typed TS interfaces (SerializedOrchardAction, AssetLockProofObject, FeeStrategyStepObject, AddressWitnessObject), but outputAddress in both UnshieldTransitionObject and UnshieldTransitionJSON is still object. Consider adding a PlatformAddressObject / PlatformAddressJSON interface for type safety consistency.

_{source: ['claude']}