[ascandone]

Problem

Two pull/send shapes pass vm.Verify and produce wrong postings with no error:

• A pull_account whose destination register is also its cap or overdraft. funds.Pull writes the destination before it reads the bounds on the bounded path, so an aliased cap stops bounding the pull and an aliased overdraft doubles the balance. Balance 30, cap 100, overdraft 0 pulls 60, leaving the source at -30 with a zero overdraft.
• A set_current_asset while funds are still queued. The debit was taken under the previous asset; the posting is emitted under the new one.

Two more are silent but less severe: a run that ends with funds still queued drops the debit, and an unverified program ending in the first word of a two-word instruction panics on the ext-word read (the old TODO in vm.go).

Compiled numscript never emits any of these: the allocator never aliases a destination with an operand of the same instruction, and every send statement either pulls exactly what it sends (check_enough_funds) or sends everything it pulled. They matter for bytecode that did not come out of this process's compiler, which is what the ledger replays.

Fix

Exec returns an InternalError for all four:

• errTruncatedInstruction on every two-word opcode (one compare before the ext-word read).
• errPullDestAliasesInput on Op_PullAccount (two byte compares).
• errSetAssetWithQueuedFunds and errEndWithQueuedFunds, via a new funds.RunState.HasQueuedFunds(). Zero-amount queue entries do not count: send [USD 0] lowers to a zero-cap pull that queues one and a zero-cap send that does not consume it.

Verify rejects the aliasing statically. The queue checks are not statically decidable (whether a capped send drains the queue depends on the balances), so they stay at run time; bytecode-verifier.md documents that under "What it does not check". instruction-encoding.md and the opcode comments carry the new traps.

Tests

• White-box bytecode tests for each check plus the zero-amount case; a verifier test for the aliasing rule (and that cap and overdraft may share a register); IR-driven tests so the shapes sit in the "sequences the compiler never emits" corpus.
• go test ./..., the difftest module, -race on the touched packages, TestCompiledCorpusPassesVerify, and 20s each of FuzzExec and FuzzMutatedBytecode are clean.

Performance

BenchmarkCompiledVM*, 10 runs each, comparing minimums: identical allocations, timings within noise except the smallest script (BenchmarkCompiledVM, 630 → 648 ns/op), which is the two HasQueuedFunds calls on an empty queue.

Not changed

• An unverified program naming a register past its bank still panics; verify-first remains the contract.
• ir.Typecheck does not know the aliasing rule. Hand-written IR with it assembles, and is caught by Verify one level down.

[NumaryBot]

The required automated review completed with no remaining findings.

[NumaryBot]

🟠 [major] Guard extension-word reads before indexing instructions

An unverified program ending with Op_PullAccount still executes instrs[pc] after pc has advanced past the final word, causing an index-out-of-range panic rather than the promised InternalError. Op_MetaMonetary retains the same unchecked read at line 437. The change removes the TODOs without implementing the stated fail-closed behavior.

Suggestion: Check that an extension word exists before each two-word instruction reads it and return an InternalError for truncation. Add direct Exec tests for each truncated opcode.

[NumaryBot]

🟠 [major] Reject aliased pull destinations at runtime

Exec still passes the destination and cap/overdraft register pointers directly to the funds engine without comparing their indices. An unverified pull whose destination aliases a bound therefore retains the malformed-bytecode behavior this PR says Exec rejects: the destination write can change the bound and allow an excessive debit. The new verifier test does not protect callers executing unverified bytecode.

Suggestion: Before invoking Pull or PullUncapped, reject a destination equal to either non-nil cap or overdraft register with InternalError, and add direct Exec regression tests for both aliases.