L-07: `clear_fpi_memory` Does Not Reset the Foreign Procedure Input Buffer

Foreign procedure invocation stores three prover-supplied values in fixed kernel memory during `tx_prepare_fpi`: the foreign account ID, the foreign procedure root, and the sixteenth foreign-procedure input value held at [`UPCOMING_FOREIGN_PROC_INPUT_VALUE_15_PTR`](https://github.com/0xMiden/protocol/blob/07ef8323cfa773e16e860311ea5b4a0c3086e3ed/crates/miden-protocol/asm/kernels/transaction/lib/api.masm#L1888-L1890). After the call completes, `tx_exec_foreign_proc` invokes [`clear_fpi_memory`](https://github.com/0xMiden/protocol/blob/07ef8323cfa773e16e860311ea5b4a0c3086e3ed/crates/miden-protocol/asm/kernels/transaction-core/src/tx.masm#L204-L212) to reset this state, but `clear_fpi_memory` zeroes only the account ID and the procedure root. The input buffer is left holding the value from the previous call.

This is currently masked because the account ID and procedure root also serve as the sentinels checked at the start of `tx_exec_foreign_proc`, which reverts with [`ERR_FOREIGN_ACCOUNT_ID_IS_ZERO`](https://github.com/0xMiden/protocol/blob/07ef8323cfa773e16e860311ea5b4a0c3086e3ed/crates/miden-protocol/asm/kernels/transaction/lib/api.masm#L1930-L1931) or `ERR_FOREIGN_ACCOUNT_PROCEDURE_ROOT_IS_ZERO` when either is zero. Reaching another foreign procedure invocation therefore requires a fresh `tx_prepare_fpi`, which unconditionally rewrites the input buffer before it can be read again, so a stale value cannot be consumed along the sanctioned path. The correctness of the reset thus depends on this ordering invariant rather than on the reset being complete. Since the memory accessors are exported and the sentinels can be written directly without going through `tx_prepare_fpi`, and since the split preparation and execution flow already carries cross-phase state hazards, relying on re-preparation instead of an explicit reset is fragile and leaves the kernel in an inconsistent state after each foreign procedure invocation.

Consider clearing `UPCOMING_FOREIGN_PROC_INPUT_VALUE_15_PTR` in `clear_fpi_memory` alongside the foreign account ID and procedure root, so that all foreign procedure invocation state is reset to a known value after each call and the correctness of the reset does not depend on the ordering of subsequent preparation steps.

---

_Copied verbatim from finding L-07 (low) of the OpenZeppelin [tx kernel programmable assets diff audit](https://audits.openzeppelin.com/miden/miden-q3-06-tx-kernel-programable-assets-diff)._