Deterministic accounts (NEP-616)

[r-near]

Background. NEP-616 lets a contract instance be deployed to an account ID derived from its init code + state, enabling sharded contract designs. It adds the DeterministicStateInit action; the receiver ID is computed, not supplied by the signer.

Current behavior. DeterministicStateInit is rejected by the action parser. The derived 0s… account IDs render as opaque strings, with no type awareness.

Work.

• Add DeterministicStateInit: parse the action's state_init and deposit.
  • state_init is versioned (currently V1, carrying a global-contract reference plus a key/value state map). Reject unknown version tags.
  • Reuse the global-contract identifier parsing from the global-contracts work.
  • The state map is arbitrary key/value data — do not materialize it; stream and display a summary (entry count + total byte size), consistent with how the app caps other unbounded fields.
  • Display the deposit and the referenced global contract.
• (stretch) Derive and display the resulting 0s… account ID so the signer sees the target account. Note: this needs keccak256 on-device — confirm the Ledger SDK exposes it before committing.

Acceptance. V1 parses and displays (deposit + contract + state summary); unknown versions are rejected; ID derivation is either implemented or explicitly deferred with rationale.

Depends on: the global-contracts issue (shares the global-contract identifier parsing).