Thread caller context through the state-read path (replace context.TODO() bridges) — for metrics, then tracing/logging

## Context

The temporal `GetLatest` unification (#21739) made the read interface `GetLatest(ctx, name, k) (v, txNum, err)`. Call sites that did not have a caller `context.Context` in scope were bridged with **`context.TODO()`** (greppable: `git grep "GetLatest(context.TODO()"` — ~33 sites across db/kv/kvcache, db/state, execution/state (ReaderV3), execution/commitment, execution/stagedsync, rpc/jsonrpc, …).

Those `context.TODO()` markers are deliberate placeholders: the *value* is correct (an empty root ctx, behaviour-identical to today), but a real caller ctx should flow there.

## What to do

Thread the real caller `context.Context` down to `GetLatest`, replacing the `context.TODO()` bridges. The notable surface is the state readers — `ReaderV3` and the `state.StateReader` interface methods (`ReadAccountData`, `ReadAccountStorage`, `ReadAccountCode`, …) — which ripples through `IntraBlockState` / the EVM and the ~10 `NewReaderV3` construction sites; plus the kvcache `Cache` interface and the commitment `StateReader` interface.

## Why (the payoff)

1. **Caller-scoped read metrics.** Today metrics flow via `SharedDomains.metrics` (process/SD-global). With ctx threaded, the metrics sink can be **caller-scoped** (per-request / per-worker, as in the lock-free collector model) and carried in `changeset.ReadContext` instead of being hard-wired to `sd.metrics`.
2. **Tracing & logging via context** (follow-on). Once the application read/exec path is generally context-aware, request-scoped tracing spans and loggers can ride the same ctx — no new plumbing.

## Refs

#21739 (the GetLatest unification that introduced the `context.TODO()` bridges). Principle recorded in `db/agents.md` ("Layering principle: txNum is the application unit; step is a db implementation detail").