Clarify and test FPI support for network-account notes

[BrianSeong99]

Problem

Pioneer feedback reports that Foreign Procedure Invocation (FPI) is unclear in network-account flows.

The concrete case was a registry network account consuming a network note. As part of that note execution, the registry needed to FPI into a newly created pool account to verify the pool account's code commitment.

For local transactions, the developer can explicitly provide or import the foreign account target before executing the transaction. For a network account, the developer submits a network note and the network performs the account update. From the application developer's perspective, there is no obvious place to enforce that the FPI target has been imported or is available to the executor.

This leaves developers with two unclear questions:

• Does FPI into a public foreign account work when the caller is a network account consuming a network note?
• If it does work, what must the developer ensure before submitting the network note?

Current node code appears to support the public-foreign-account case, but this behavior is hard to discover from user-facing docs and should have clear regression coverage.

Why this matters

Network accounts are the path for shared public state. Developers building registries, AMMs, or other shared-state apps need to know whether a network note can safely validate state from another public account during execution, and what preconditions are required.

If this behavior is supported but undocumented, developers may incorrectly assume FPI is unsupported for network transactions. If it is only partially supported, the limitations should be explicit and diagnosable.

Proposed scope

Add a small regression/documentation pass for the registry/pool-style flow described above:

• add or identify a node-level test where a network account consumes a network note and performs FPI into another public account,
• make the test assert the foreign account is fetched at the reference block and its code is available during execution/validation,
• update docs/external/src/... in the node repo so the source docs ingested into docs.miden.xyz explain the developer-facing preconditions,
• specifically document that the FPI target must be public and retrievable by the network/store at execution time,
• document expected behavior when the foreign account is private, missing, or otherwise unavailable,
• ensure failures are observable through GetNetworkNoteStatus.last_error,
• link the result from the MASM network account tutorial/docs work.

No implementation change should be needed unless the test exposes a gap.

Acceptance criteria

• A reproducible test or example confirms a network account can consume a network note that performs FPI into a public foreign account.
• Node source docs state whether this flow is supported.
• Docs specify what the developer must ensure before submitting the network note, especially around the public availability of the FPI target.
• Unsupported cases, such as missing/private foreign account data, are documented with expected diagnostics.
• The result is linked from the MASM network account tutorial/docs work.

Source notes

Implementation pointers for maintainers:

• crates/ntx-builder/src/actor/execute.rs: NtxDataStore::get_foreign_account_inputs()
• crates/ntx-builder/src/clients/store.rs: StoreClient::get_account_inputs()
• crates/validator/src/tx_validation/data_store.rs: validator reloads foreign account code from transaction inputs
• 0xMiden/node#1598
• 0xMiden/tutorials#193
• 0xMiden/node#1758
• 0xMiden/node#1818
• 0xMiden/protocol#1873
• 0xMiden/protocol#1888

[AlgofootPrint]

Hi, I’d like to take this one if it’s available.

Proposed scope:

• trace the existing NTX execution path through NtxDataStore::get_foreign_account_inputs() and validator reload of foreign account inputs,

• add focused regression coverage for a network account consuming a network note that performs FPI into a public account,

• document the developer-facing preconditions in docs/external/src/..., including that the FPI target must be public and retrievable by the store at
  execution/reference block time,

• document expected diagnostics for missing/private/unavailable foreign account data via GetNetworkNoteStatus.last_error.

  I’ll keep the PR limited to tests/docs unless the regression exposes a real implementation gap. Could you assign this to me?

[Mirko-von-Leipzig]

I'm unsure if this documentation belongs in the node; this seems more like a protocol level explanation of network accounts? @PhilippGackstatter - thoughts?

How the node implements them is largely irrelevant to anyone outside of the node developers.

[PhilippGackstatter]

With the recent refactors in the protocol, the network note and network accounts, and arguably the network transaction feature at large, is a miden-standard. So the docs for it should probably go into the "standards docs" (in the works 0xMiden/protocol#2835).

I think the protocol team can own the docs for network note and network account standards, specifically:

• NetworkAccountTarget attachment for network note identification
• the NetworkAccount auth account component recently added (feat(standards): add NetworkAccount auth component protocol#2817) which is slated to replace AccountStorageMode::Network

For the parts built on top of the standards (network note retries, FPI support, ...) the implementation matters, so it seems it would be good for someone from the node team to own those parts. I think ideally we'd write some kind of specification for network transactions, what the implementation guarantees or doesn't, etc. that would go into those docs.