…nd CommitmentRoot (#21026)

`CommitmentRoot` has a subcheck `checkCommitmentRootViaRecompute`: it
touches/replays content of the final block in commitment.kv file and
does `ComputeCommitment`. The resulting root hash should remain
unchanged.

`RebuildCommitment`: it creates shard of size 16 and ultimately merged.

Both need contrainted/limited query of state data (i.e. only return
value for key K from before step X)

both suffer from 2 problems today:
- `getLatestFromFiles(maxTxNum)`: it effectively searches only a single
kv file (the one that contains maxTxNum). The files "left and right" of
it are ignored.
- `LimitedHistoryStateReader`: if `getLatestFromFiles(maxTxNum)` returns
nil, it fallbacks to GetLatest.

This creates problem like:
- commitment prefix is queried, it's not there in current step range.
It's there in some previous file, so it'd return nil (because of
`getLatestFromFiles` logic)
- say we're building 128-192 range, we look for a storage slot key which
became nil in this range; `LimitedHistoryStateReader` would fallback on
GetLatest in this case.

FilesOnlyStateReader: it's essentially LimitedHistoryStateReader,
without the fallback on `GetLatest`.

the problem is mentioned above. The fix simply walks back from "maxTxNum
containing snapshot" to the first snapshot.
The change only impacts when `maxTxNum != uint64.max` which is used in
`FilesOnlyStateReader`, `checkCommitmentRootViaFileData` and `commitment
print` command.

domain.
- `checkCommitmentRootViaRecompute` — switch from account-domain-only
`touchHistoricalKeys` to `sd.TouchChangedKeysFromHistory` (accounts +
storage; code is covered transitively via `account.codeHash`). This is
the same helper used by `rpc/rpchelper/commitment.go` and receipts
generation.

(cherry picked from commit a81cc87)