perf(indexes): make mostly-NULL secondary indexes partial

[iemejia]

Summary

Migration 0023 makes three mostly-NULL secondary indexes partial (WHERE <col> IS NOT NULL):

• worker_queue.session_id — NULL for every non-session work item
• worker_queue.tag — NULL for every untagged (default) work item
• orchestrator_queue.lock_token — NULL for every unclaimed row

Why

Each of these columns is NULL for the majority of rows, yet a plain B-tree still stores an entry for every row (including the NULLs). Each index is only ever probed by a concrete non-NULL value — session routing/takeover, tag routing, and the orchestrator ack DELETE … WHERE lock_token = <token> — so the NULL entries are pure overhead: they bloat the index and add maintenance/autovacuum work that no query benefits from.

Fix

Recreate the three indexes as partial WHERE <col> IS NOT NULL. Postgres skips a partial index entirely for rows that don't satisfy its predicate, so the ~95% of inserts with a NULL value now do no work on these indexes — no index tuple, no page split, no WAL, and nothing for autovacuum to reclaim later. That is the source of the speedup; it is a write-path win, not a lookup change. Reads by a concrete value still use the indexes.

Measured

500k worker rows (~5% sessioned/tagged), 100k orchestrator rows (~10% claimed):

Index	Before	After	Reduction
idx_worker_queue_session_id	3264 kB	272 kB	~12×
idx_worker_queue_tag	3168 kB	176 kB	~18×
idx_orch_lock	1120 kB	536 kB	~2×
bulk insert of 500k rows	1576 ms	1329 ms	~16% faster

Reproduce with scripts/bench-secondary-indexes.sh.

Trade-off

This is a distribution-dependent write-path optimization. The savings scale with how NULL-heavy the columns are (the figures use a ~95%-NULL, i.e. non-session/untagged, population); a session- or tag-heavy workload sees little benefit — but no regression, as value lookups still use the indexes. The parameterized tag = ANY($1) was verified to still use the partial index even under a forced generic plan. The only path dropped is an IS NULL index scan, which the planner never chose anyway (NULL is the majority value → seq scan).

Notes

• Migration numbering: 0022 is reserved by the concurrent worker_queue dequeue change; this migration is independent of it. The runner applies pending migrations by version and tolerates the gap, so 0023 applies cleanly with or without 0022 present.

Testing

• basic_tests, postgres_provider_test (incl. session + tag-filtering), and session_e2e_tests all pass.
• Migration verified to apply via both psql and the crate's own migration runner (partial indexes present and value lookups still index-served in freshly created schemas).

Related: #18. That PR takes migration 0022; this one is 0023 and is independent of it.