[DRAFT] Optimize query-path caching/memoization

[cjonas9]

Supersedes #1003, which GitHub auto-closed as merged into bypass-jrpc2-marshal when the stack was reordered to put this PR first. What little review history exists for this PR lives there.

What

Adds latestMemo[T] in methods/latest_memo.go, an atomic pointer to a {seq, value} entry plus a miss mutex. A new ledger invalidates it by moving the key, so there is no ingestion hook.
This is used so that...

• getLatestLedger memoizes its rendered response.** The fully rendered JSON is cached keyed by ledger sequence.
• getNetwork and getVersionInfo also benefit from this, as getProtocolVersion now memoizes the result by sequence with the same latestMemo.

You can compare the optimized performance seen in coordinator runs here to the base perf measured in #1018. The results in the coordinator runs here include all recent optimization work -- XDR views adoption (#945, #962, #941, #1035, all validated by tests in #976, #982), as well as more recent tangential optimizations (see the stack, particularly #1036, 1037, and this PR).

Measurements

Handler-level, from the perf-eval go-bench leg on this branch (pubnet-sized ledger):

	time	B/op	allocs/op
GetLatestLedger, uncached	8.8 ms	11.2 MiB	40
GetLatestLedger, cached	1.06 µs	164 B	5

getNetwork over the pubnet sqlite fixture (BenchmarkLedgerReads harness; v1 sqlite / v2 hot). getVersionInfo tracks it within noise:

	time	B/op	allocs/op
before	4.2 ms / 4.4 ms	10.5 MB / 9.2 MB	103,000
header view read	175 µs / 264 µs	1.5 MB / 8.7 KB	~200
view + memo	10 µs / 13 µs	5 KB / 6 KB	~120

The memo row is getHealth cost. The 103K allocations per call were what made these endpoints fold under concurrency.

Tests

• getLatestLedger: serves the memo until the ledger advances, an older view does not evict a newer render, 32 concurrent misses render once, errors are not memoized, and the rendered bytes are byte-equal to marshaling the response struct.
• Protocol version: same memo behaviour, plus getNetwork doing one raw read across two requests.
• BenchmarkGetLatestLedger gained cached and uncached rows.

Why

getLatestLedger, getNetwork and getVersionInfo are what SDKs and wallets poll continuously, and they were the first endpoints to buckle under load even though their answers change once per ledger. Proportionate to what they return, they were made needlessly expensive because every request touched the 2 MB latest ledger. This is a full decode for one field or a base64 render of the whole thing.

Known limitations / additional notes

• Per-handler memos, not one shared cache. getLatestLedger, getNetwork and getVersionInfo each hold their own. A shared one would need wiring through specs.go, and a getNetwork miss would then either trigger the 2 MB render or need per-field laziness.