Optimize `GetAccount` all-entries storage map fallback for partial reverse-key cache misses

Follow-up from PR comment: https://github.com/0xMiden/node/pull/2012#pullrequestreview-4396515696

When `GetAccount` handles an `AllEntries` storage-map request, it first tries to read entries from the account state forest. This works only if every `hashed_key -> raw_key` mapping is present in the forest reverse-key LRU cache. If any mapping is missing, the current code falls back to `reconstruct_storage_map_details_from_db()`, which reconstructs the full storage map from the DB and then backfills the cache.

There may be a more targeted fallback here. Instead of reading full map details from the DB when only some reverse-key cache entries are missing, we could fetch or reconstruct only the missing key mappings.

Potential approaches:

- Add a DB helper such as `get_storage_map_key_mapping(account_id, slot_name, block_num, hashed_keys)` that returns raw keys for the missing hashed keys.
- Store hashed keys in `account_storage_map_values`, for example as an additional column, so missing mappings can be queried directly.
- Alternatively, since all-entries responses are bounded by `AccountStorageMapDetails::MAX_RETURN_ENTRIES` currently 1000, read the raw keys for the map and hash them locally to recover only the missing mappings.

The main tradeoff is complexity and storage overhead versus avoiding full DB reconstruction on partial cache misses. This issue should explore whether the optimization is worthwhile and, if so, what API/schema shape would be appropriate.