[EASY] solana-indexer: add the settlement slot to trades

[squadgazzz]

Description

The analytics team copies Solana tables incrementally: each run fetches the rows past the highest key it has already seen. On EVM, trades has block_number for that. solana.trades has no slot column, so their extraction has to join solana.settlements to get one.

This PR adds slot to solana.trades, like block_number on the EVM trades table. The indexer writes each trade in the same DB transaction as its settlement row, and deletes both together when the Solana transaction vanishes before finalization. So a trade's slot always matches its settlement's. The migration backfills existing trades from solana.settlements, then sets NOT NULL and indexes slot. A trade without a settlement row makes the migration fail and roll back.

The migration is V12, because #4976 holds V10 and #4998 holds V11. It merges after both, or gets renumbered.

Changes

• solana.trades.slot: bigint NOT NULL, backfilled from solana.settlements, with an index on slot
• The indexer stores the settlement's slot on each trade

How to test

Updated DB tests. I also ran the migration in a rolled-back transaction: it copied the settlement's slot, and a trade without a settlement made it fail cleanly. Before merging, this should return 0 on staging:

SELECT count(*) FROM solana.trades t
LEFT JOIN solana.settlements s USING (tx_signature, instruction_index)
WHERE s.slot IS NULL;

[claude]

Claude finished @squadgazzz's task in 1m 47s —— View job

---

PR Review: add settlement slot to Solana trades

• Read the changed files and diff
• Review migration SQL (V12__trades_slot.sql)
• Review indexer persistence changes
• Review db.rs / observation.rs query changes
• Check all INSERT INTO solana.trades sites are consistent

Verdict: LGTM — no blocking issues found, no inline comments needed.

What I verified:

• Consistency guarantee holds. The production insert (persistence.rs:316) binds to_db_slot(settlement.slot), the same value written to solana.settlements in the same DB transaction (apply_settlement_finalized), and the revert path deletes trades + settlements together (persistence.rs:456-457). So a trade's slot always matches its settlement's, as claimed.
• No stray insert sites. All four files that INSERT INTO solana.trades (indexer + orderbook + autopilot-svm tests) add the new slot column/bind — nothing left that would break under NOT NULL.
• Migration conventions match. Index name solana_trades_slot follows the existing solana_* pattern (cf. solana_settlements_slot in V3), plain CREATE INDEX is consistent with prior migrations, and Flyway wraps the migration in a transaction so a leftover orphan trade rolls the whole thing back cleanly.
• Tests updated correctly, including the tightened assertion that now checks the resolved uid and the settlement slot ((uid, 20)).

Non-issues (already acknowledged in the description, noted only for the record):

• V10 numbering gap (solana-orderbook: cancel pending sponsored orders off-chain #4976 holds V10) — flagged for renumber-on-merge.
• Backfill fails hard on any trade lacking a settlement row — intentional, with the staging pre-merge check provided.
  · solana-indexer/trades-slot