New MDX page at content/api-reference/solana/historical-account-state.mdx covering the two supported workflows for reconstructing point-in-time Solana account state: forward snapshotting via Yellowstone gRPC subscriptions and historical backfill via getSignaturesForAddress + getTransaction replay. Includes guidance on sampling cadence, filter options, gRPC reconnect via from_slot replay, and a trade-offs comparison. Added under the Solana section in docs.yml alongside AccountsDB Infrastructure.

Refs DOCS-84

Requested-by: @SahilAujla

Addresses codex review feedback on PR #1303: a single Solana slot can contain multiple writes to the same account, so indexing by (pubkey, slot) alone makes 'latest version at or before slot N' ambiguous and can return an earlier intra-slot state. Update the storage layout and the SQL example to use (pubkey, slot, write_version) for indexing and ORDER BY slot DESC, write_version DESC LIMIT 1 for the snapshot lookup. Add a paragraph explaining what write_version is and why the tie-break matters.

Refs DOCS-84

Requested-by: @SahilAujla

Addresses review feedback from @deepakbnsl on PR #1303. The original workflow B description and TypeScript example implied that getTransaction is sufficient to reconstruct arbitrary program account data, which is incorrect — getTransaction returns pre/post lamport balances, pre/post token balances, inner instructions, and log messages, but NOT pre/post account data blobs.

Changes:

* New 'What getTransaction provides' subsection enumerates what the response actually contains and explicitly notes the absence of pre/post account data fields.

* New Warning callout scoping workflow B to SOL lamport balances, SPL token balances, and program-emitted log events. Documents that arbitrary program account data reconstruction requires either a starting data snapshot + program-specific instruction decoding, or comprehensive event logs from the program.

* Rewrote the Pattern subsection to be concrete about reading meta.postBalances at the target account index, and clarified that meta.preBalances at T+1 equals meta.postBalances at the most recent earlier touching transaction so the post-side is the canonical value per slot.

* Rewrote 'When you need program-account state, not just a single account' as 'When you need program-account state, not just balances' with the correct guidance: enumerate via getProgramAccounts for current data, start workflow A for ongoing changes, treat the subscription start as the history-begins-here marker. External-snapshot bootstrap or program-side replay flagged as out-of-scope for this guide.

* Replaced the TypeScript example with a concrete lamport-balance backfill that locates the target account's index in transaction.message.accountKeys and persists meta.postBalances[i]. Added a note about extending to token balances and log events.

* Updated the workflow comparison table: 'Reconstruction effort' row replaced with 'Data captured' to clearly distinguish what each workflow returns (full account bytes vs balances + log events only).

* Updated the closing 'combine the two' paragraph to reflect the correct combined workflow.

Refs DOCS-84

Requested-by: @SahilAujla