store: AllEntries paged SQL queries for vault assets and storage slots share the same saturating_sub(1) underflow bug as storage maps (just fixed in #1816)

[giwaov]

Summary

PR #1816 (merged today) fixes a critical underflow in \select_account_storage_map_values_paged:

Root cause: \last_block_num.saturating_sub(1)\ computes -1\ (i64) when all entries share the same genesis block, which fails \BlockNumber::from_raw_sql.

The same pattern almost certainly exists in the other paged storage helpers:

• \select_account_vault_assets_paged\
• \select_account_storage_slots_paged\
• Potentially other paginated queries that derive a block range via \saturating_sub(1)\ from the most recent block seen.

Reproduction

Any account whose vault or storage slots were populated entirely in genesis block 0 e.g. the bridge account, faucet, or genesis accounts in integration tests will trigger an internal server error when \GetAccount\ is called with \AllEntries(true).

\
GetAccount { AllEntries: true }
select_account_vault_assets_paged last_block_num.saturating_sub(1) = -1
BlockNumber::from_raw_sql fails
Internal error returned to caller
\\

Suggested fix

Audit every *_paged\ SQL helper in \miden-node-store\ for the \saturating_sub(1)\ pattern and apply the same boundary fix from #1816 symmetrically: when \ ake_while\ yields empty results (all entries in a single block), return \�lock_range.start()\ to signal no pagination progress, which correctly triggers the \limit_exceeded\ path in the caller.

Impact

Silent data corruption / internal error for any accounts fully initialised in block 0, which includes canonical genesis accounts and all integration test scenarios that seed state before the first non-genesis block.