fix(api): respect historical block in v2 storage entries

[rossbulat]

Fixes #753.

Summary

• forward the historical atBlockHash when V2 storage map enumeration calls chainHead.storage
• add a regression test asserting entries() uses the block hash from an api.at(...) client

Without the hash, descendantsValues resolves against the latest state, so historical map enumeration can silently return current entries even though keyed historical queries are correct.

Tests

• yarn workspace @dedot/api test StorageQueryExecutorV2.spec.ts
• yarn build

[Copilot]

🟢 Approval recommended

The change correctly forwards the historical block hash to chainHead.storage in the affected path and includes a targeted regression test covering the reported failure mode.

Pull request overview

This PR fixes a JSON-RPC v2 historical query correctness bug where storage map enumeration (entries(), via descendantsValues) could silently resolve against the latest chain state instead of the block specified by an api.at(blockHash) client.

Changes:

• Forward atBlockHash to chainHead.storage for V2 storage map enumeration (descendantsValues) so results are resolved at the intended historical block.
• Add a regression test asserting that entries() uses the historical block hash from the client when calling chainHead.storage.

File summaries

File	Description
packages/api/src/executor/v2/StorageQueryExecutorV2.ts	Passes this.atBlockHash into chainHead.storage for descendantsValues map enumeration.
packages/api/src/executor/tests/StorageQueryExecutorV2.spec.ts	Adds a regression test validating the historical block hash is forwarded during entries() calls.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.