Summary

The Aerospike UTXO store's two spend paths (Lua and expression-based) diverged from the SQL store and bitcoin-sv at the freeze-expiry boundary. An Aerospike-backed node was strictly stricter than the rest of the network: it refused to mine or accept transactions that SQL/svnode considered valid.

Reference behaviour comes from svnode's CFrozenTXOCheck (bitcoin-sv/src/frozentxo_db.h): enforceAtHeight intervals are evaluated half-open with nHeight < i.stop — the freeze window is closed at start, open at stop. A UTXO becomes spendable AT stop.

Two related fixes ship together so all three storage paths (SQL, Aerospike Lua, Aerospike expression) make identical accept/reject decisions.

Fix 1 — Aerospike Lua boundary off-by-one (T5a)

stores/utxo/aerospike/teranode.lua:373 used >= which kept the UTXO frozen at currentBlockHeight == spendableIn. The SQL store uses strict < in all three call sites (sql.go:2071, 2557, 3346). Flipped to > so the UTXO becomes spendable AT spendableIn, matching SQL/svnode.

Fix 2 — Aerospike expression-path strictness (T25)

stores/utxo/aerospike/spend_expressions.go rejected ANY record with utxoSpendableIn set, regardless of the per-offset value, because Aerospike filter expressions cannot inspect map values — only check bin existence.

Picked Option B2a from the issue (over-retry through Lua):

• Kept the conservative ExpNot(ExpBinExists(UtxoSpendableIn)) guard as defense in depth — a record needing per-offset comparison must never reach ListSetOp through the expression path.
• Added retry-through-Lua: processSpendBatchResultsExpressions now collects FILTERED_OUT records and re-dispatches them via a single batched Lua call, which compares per-offset and produces the correct accept/reject decision with the precise rejection reason (ErrFrozen, ErrSpent, ErrTxConflicting, etc.) — rather than the previous generic "spend validation failed".
• Extracted the Lua execution from sendSpendBatchLua into executeLuaSpendBatch so both the primary Lua route and the expression retry share the same implementation.

Cost: one additional batched Lua call per expression batch that has any FILTERED_OUT records. The cost is independent of how many records were filtered out — they all go through in the same batch — and is only paid when at least one record needed re-evaluation. In steady state most spends pass the expression filter, so this is paid only on already-failing records. The conservative guard means the safety property holds even if the retry logic has a bug.

Observability

Two new Prometheus counters give operators visibility into how often the expression path is falling back to Lua — the only quantitative signal that the conservative utxoSpendableIn guard is hot:

• teranode_aerospike_utxo_spend_expression_lua_retry — counter incremented per expression batch that triggered a retry (rate divided by utxo_spend_batch gives the batch-level retry fraction).
• teranode_aerospike_utxo_spend_expression_lua_retry_records — counter incremented per record re-dispatched through Lua (rate divided by utxo_spend gives the per-record retry fraction).

Test plan

New tests in stores/utxo/aerospike/spend_spendable_in_boundary_test.go, all run against a real Aerospike container via testcontainers-go:

• TestStore_SpendableInBoundary — boundary at spendableHeight - 1 (reject), == spendableHeight (accept after fix), + 1 (accept). Runs against both Lua and expression paths.
• TestStore_SpendableInExpressionParity_PastValueAccepted — record with utxoSpendableIn set to a long-past value is spendable through both paths.
• TestStore_SpendableInExpressionParity_FutureValueRejected — record with utxoSpendableIn strictly in the future is rejected through both paths with ErrFrozen (the safety property the guard enforces).
• Full go test ./stores/utxo/aerospike/... suite passes (178s with containers).
• No regression in go test ./stores/utxo/sql/....
• No regression in go test -tags testtxmetacache ./services/validator/....

Acceptance criteria (from bitcoin-sv/teranode#4640)

• At blockHeight == spendableIn, all three store paths accept the spend.
• At blockHeight == spendableIn - 1, all three reject.
• A record with UtxoSpendableIn set whose values are all past is spendable through both Aerospike paths.
• The Aerospike expression path never spends a record whose UtxoSpendableIn map contains a value > currentBlockHeight for the output being spent.
• No regression in SQL or validator tests.

Closes bitcoin-sv/teranode#4640