feat(solana-indexer) PR16: write created and traded order events

[squadgazzz]

Description

The indexer now writes the order events for the flows it observes: created when it inserts a solana.orders row, traded when it inserts a solana.trades row, each in the same transaction as the row itself. The rows_affected gates keep replays idempotent, a conflicted insert writes no event. On EVM the components observing these flows write the same labels, on Solana that observer is the indexer.

Neither write takes the advisory lock #4775 uses, because neither needs a dedup read: the gate is whether the row insert won its unique constraint, and Postgres serializes that already. The two writers stay clear of each other by owning disjoint labels, created and traded here against ready, executing and considered in the autopilot. A writer that takes a label from the other's set needs the lock too.

Changes

• created and traded order events written atomically with their orders/trades rows

How to test

Extended the batch-persistence Postgres test: exactly one event per inserted row, stable under replay.

[claude]

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

---

PR Review: write created and traded order events

• Read the diff and surrounding persistence.rs context
• Check the solana.order_events schema/enum
• Verify idempotency gates and the extended test
• Post findings

Verdict: Looks good. The design is sound: each event is gated on rows_affected > 0 of its row insert, and since both inserts are ON CONFLICT DO NOTHING, replays write nothing — so the append-only event log stays exactly-once without needing the advisory lock. The extended test nails the interesting case (seeded order → only traded, fresh order → only created, stable across a second replay).

I left one minor, optional note inline. Nothing blocking.
· solana-indexer/be-242-order-events