perf(server): drop the unused event correlation index
Fork review PR (review only; the upstream submission will use this same diff).
Every event append maintains an index no query reads: idx_orch_events_correlation_id occupies 48 MB on a real 3.0M-event database and costs one index write per inserted event.
Problem: orchestration_events.correlation_id is selected back out when rows are decoded, but no query in the server filters, joins, or orders by it (verified by searching all SQL in apps/server/src for correlation_id predicates; only column lists match). The neighboring command_id and agent_stream_sequence indexes stay untouched: both are named by INDEXED BY in live queries (OrchestrationEventStore readByCommandId/high-water reads, LegacyV1ThreadImporter).
Change: migration 069 drops the index. One fewer index (9 to 8) maintained per event append; 48 MB reclaimed as freelist on the measured database. No behavior change. Note: a sibling PR (thread-search FTS) also adds a migration 069 from the same base; whichever lands second renumbers.
Evidence: index sizes from dbstat on a VACUUM INTO copy of a real 18.7 GB install (3,038,388 events, correlation_id non-null on 265,973): correlation index 48 MB. FoundationPersistence + ThreadSearch suites pass on head 2882ed6de9 (41 tests, migrations run in-memory).
Muse Wonder Full 1.0, in Muse Code (via T3 Code)
Summary by cubic
Drops the unused idx_orch_events_correlation_id index on orchestration_events so event appends no longer maintain an index no query reads.
No query filters, joins, or orders by correlation_id; the column is only selected back out. The index cost one write per inserted event and occupied 48 MB on a real 3.0M-event database. The neighboring command_id and agent_stream_sequence indexes stay: both are named by INDEXED BY in live queries. A sibling thread-search PR also adds migration 069 from the same base; whichever lands second renumbers.