perf(migration): qualify the ORDER BY so the notification copies use their index #1124

nostream-storage's scan_batch (used by nostream-cli migrate pg-to-lmdb) builds

SELECT {columns} FROM {table} [WHERE key > $1] ORDER BY key LIMIT $2

For notification_outbox and notification_delivery_log the column list is OUTBOX_COLUMNS / DELIVERY_LOG_COLUMNS, which begin id::text AS id. In PostgreSQL an ORDER BY name resolves to the output column first, so ORDER BY id sorts the text expression, not the uuid column. The indexes cover the uuid column, so each batch reads the remaining rows and sorts their text ids before applying LIMIT.

Correctness is unaffected: canonical uuid text has fixed dash positions, so lexicographic text order on lowercase hex agrees with PostgreSQL's byte-wise uuid order, and the keyset predicate (id > $1::uuid) stays consistent with the sort. The cost is the repeated sort, paid while the relay is stopped.

Acceptance

ORDER BY and the keyset predicate name the table (ORDER BY notification_outbox.id, notification_outbox.id > $1::uuid), so the plan can walk the uuid index and stop after LIMIT rows instead of sorting each batch.

Verify with EXPLAIN on both notification tables before and after: before shows a Sort above the scan; after, an index scan with no sort node. A test can assert the generated SQL names the table in both clauses, but the plan is the evidence.

Where it came from

Static review round 18 on factory/029-pg-to-lmdb (finding P2, non-blocking). The branch is frozen for review, so it was not fixed there.