spec(XLS-65): Update VaultCreate failure conditions and state changes

[Tapanito]

Syncs the VaultCreate spec section with the current implementation in src/libxrpl/tx/transactors/vault/VaultCreate.cpp.

Data Verification (3.2.5.1) — was _TBD_, now populated:

• Data > 256 bytes
• Invalid WithdrawalPolicy value
• DomainID = 0
• DomainID without tfVaultPrivate
• Negative AssetsMaximum
• Empty or oversized MPTokenMetadata
• Scale with XRP or MPT asset
• Scale > 18 for IOU asset

Protocol-Level Failures (3.2.5.2) — reorganised and extended:

• Removed preflight checks (moved to Data Verification above)
• Added terNO_ACCOUNT, terNO_RIPPLE for IOU issuer checks (from canAddHolding)
• Added tecWRONG_ASSET for pseudo-account issuers
• Added tecLOCKED for MPT lock (global or per-account, via isFrozen)
• Added terADDRESS_COLLISION for pseudo-account address collision
• Added error codes to all items

State Changes (3.2.6) — extended:

• MPTokenIssuance flags based on tfVaultShareNonTransferable and tfVaultPrivate
• Authorized MPToken for pseudo-account when vault is private
• XRP case: no holding object created
• OwnerCount incremented by 2

[tyalymov]

This PR syncs the spec with the current VaultCreate code, so I want to flag one thing. The order of the failure conditions in 3.2.5.2 differs from the evaluation order in VaultCreate.cpp, and that order is observable: when several conditions hold at once, the transactor returns the first one it hits.

Order in the code:
preclaim (checks run in this order):

1. canAddHolding — can the vault's pseudo-account hold this asset at all:
   IOU: terNO_ACCOUNT (issuer account missing),
   then terNO_RIPPLE (issuer has no DefaultRipple)
   MPT: tecOBJECT_NOT_FOUND (no MPTokenIssuance),
   then tecNO_AUTH (token not transferable)
2. tecWRONG_ASSET (issuer is a pseudo-account)
3. freeze/lock: tecFROZEN (IOU) / tecLOCKED (MPT)
4. domain missing: tecOBJECT_NOT_FOUND
5. terADDRESS_COLLISION

doApply (runs after all of preclaim):
6. tecINSUFFICIENT_RESERVE
Two places where the spec list disagrees:

tecWRONG_ASSET vs freeze/lock. The spec puts the freeze/lock checks (1.3 and 2.3) before tecWRONG_ASSET (item 3), but the code checks the pseudo-account issuer first. So for an asset whose issuer is a pseudo-account and is also frozen, the spec implies tecFROZEN/tecLOCKED while the code returns tecWRONG_ASSET.

tecINSUFFICIENT_RESERVE vs terADDRESS_COLLISION. The spec lists reserve (item 5) before address collision (item 6). In the code the collision check is in preclaim and the reserve check is in doApply, which runs later, so the order is reversed.

Is the numbered list meant to be the evaluation order? If so, can we move items 3 and 5/6 to match preclaim and doApply? If it is just a list of conditions with no order implied, a one-line note saying so would help, so nobody reads a precedence into it.

[Tapanito]

Good catch, and yes — the list is meant to reflect evaluation order. Verified against VaultCreate.cpp: tecWRONG_ASSET (pseudo-account issuer) is checked in preclaim before the freeze/lock check, and terADDRESS_COLLISION (preclaim) happens before tecINSUFFICIENT_RESERVE (doApply, which runs strictly after preclaim). Reordered 3.2.5.2 to: canAddHolding checks (1–2) → tecWRONG_ASSET → freeze/lock → domain missing → terADDRESS_COLLISION → tecINSUFFICIENT_RESERVE.

[tyalymov]

The Scale row says the field is ignored for XRP and MPT, but 3.2.5.1 item 7 in this same PR rejects it with temMALFORMED. VaultCreate.cpp:92-96 does the latter: if Scale is present and the asset is XRP or MPT, preflight fails. "Rejected" would be the accurate word here.

The "not stored on the Vault object" half is right: VaultCreate.cpp:243 only writes sfScale when the value is non-zero.