Wire the v2 stores into the API handlers and support both v1 and v2 #772

TL;DR

Serve the RPC API from the v2 stores. v1 and v2 will coexist through a deprecation window, so the v1 code is not removed as originally planned: both binaries build from this repo and share the JSON-RPC handlers, with the data layer abstracted behind store interfaces so the same handler runs over the v1 SQLite stores or the v2 hot + cold stores.

Architecture

1. One repo, two binaries. The existing v1 binary keeps its SQLite ingestion and stores; the v2 binary runs the v2 ingestion, lifecycle, and stores. Separate binaries keep the v1 artifact's dependency footprint unchanged (the v2 stores bring in RocksDB/CGO, which the v1 binary should not carry).
2. Shared handlers over store interfaces. The interfaces are designed around what the handlers need, not inherited from today's internal/db shapes; this is the opportunity to refactor the serving path into its cleanest form. Each interface gets two implementations: SQLite-backed, and v2-backed behind the query router from Implement concurrent query serving: ingestion changes and the query router #865. The seam covers ingestion-fed serving state as well as store reads (getFeeStats serves from in-memory fee windows populated by ingestion, so both pipelines must feed them).
3. Separate ingestion pipelines. Both binaries build from the same SDK, so a protocol release is absorbed once and reaches both at build time.
4. Figure out the testing story for the shared handlers: unit tests on the handlers and integration tests, covering both the SQLite-backed and v2-backed configurations.

Endpoints

Every endpoint reads the ledger range and the protocol version, so every endpoint needs at least that much backed by the v2 stores.

Cut over to the v2 stores behind shared handlers:

• getLedgers
• getTransaction / getTransactions
• getFeeStats (fee windows fed by v2 ingestion)
• getLatestLedger, getHealth, getNetwork, getVersionInfo (ledger range and protocol version only)

Ledger-entry state comes from captive core, not the stores; these read only the ledger range:

• getLedgerEntries, simulateTransaction, sendTransaction

Events:

• getEvents and the getTransaction events.parsed field are tracked in Implement the v2 events endpoint and deprecate the existing getEvents #774. Their API and query semantics are out of scope here, but the event store plugs into the same store interfaces, query router, and reader-safety contract this issue establishes, so the interface design must be aligned with Implement the v2 events endpoint and deprecate the existing getEvents #774.

Outcome

• The feature/full-history branch is merged to main and retired. v1 and v2 are maintained together on main in this repo from then on.

Depends on

• Design: concurrent query serving across all data types #770 (concurrent serving design) and Implement concurrent query serving: ingestion changes and the query router #865 (query router, implemented in PR Query routing: serving foundation (write + read side) #894).