feat(TC-1274): add epoch_order (space, parent, child) index migration

CHANGELOG.md

@@ -2,6 +2,7 @@
 
 ## [Unreleased]
 
+- New migration `m20261017_000000_epoch_order_space_index` adds `idx_epoch_order_space_parent_child ON epoch_order (space, parent, child)` for the head-epoch anti-join that every write runs under its space lock (TC-1274). On a fresh database the build is instant. On PostgreSQL, if a valid index of that name and shape already exists, the migration issues no DDL and takes no lock on `epoch_order`. If the index of that name is INVALID or has a different shape, the boot fails, and nothing is applied, with an error naming the fix. On an existing database **without** the index, the migration builds it inside the boot's migration transaction. That holds a SHARE lock that blocks writes for the whole build, and the lock wait is bounded by the 30 s `lock_timeout` (TC-1176). **Runbook (PostgreSQL, before upgrading a node with history):** in autocommit, run `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_epoch_order_space_parent_child ON epoch_order (space, parent, child);`. Then confirm `SELECT indisvalid FROM pg_index WHERE indexrelid = 'idx_epoch_order_space_parent_child'::regclass;` returns `t`. If it returns `f`, run `DROP INDEX CONCURRENTLY idx_epoch_order_space_parent_child;` and build it again. `down` keeps the index. MySQL is covered only by the generated statement, because the full MySQL migration chain does not run (TC-1314).
 - Request events include validated/echoed UUID correlation, typed replacement flags, node-keyed target account/space pseudonyms and per-request database acquisition/execution timings and attempt counts. Driver/actor instrumentation includes failures and request-awaited audit batches; forwarding requires explicit first-party origin classification. A shared core `Pseudonymizer` preserves existing account/space hashes, adds the service/space-scoped database hash primitive for F6, and is derived once at startup for injection into consumers. See `docs/request-telemetry.md` for the wire contract, key custody, restart joinability and coverage/exclusions (TC-959 N2).
 - CACAO/SIWE delegation ingestion normalizes ECDSA recovery IDs 0/1 to 27/28 before hashing and persisting the canonical DAG-CBOR bytes (TC-1071). Equivalent low-s signatures now share one delegation CID, including the CID used for revocation lookup. High-s signatures are rejected during decoding, matching the existing EIP-191 verifier and EIP-2 low-s convention; UCAN/JWS bytes remain unchanged. Existing stored delegation IDs are not rewritten.
 - Synchronize the standalone M1, W5 and load-signer Cargo locks with CACAO's `k256` dependency so `--locked` dependency resolution succeeds (TC-1071). Keep the load signer compatible with the SDK's default invocation lifetime.

tinycloud-core/src/migrations/m20261015_000000_delegation_cursor_index.rs

@@ -99,17 +99,20 @@ mod tests {
     /// database exactly as before so a later boot can apply it.
     #[tokio::test]
     async fn postgres_cursor_index_fails_fast_while_delegation_is_locked() {
-        let Some(fixture) =
-            PostgresTestSchema::new("postgres_cursor_index_fails_fast_while_delegation_is_locked")
-                .await
+        // The state a node upgrading to this migration boots with.
+        let this = crate::migrations::Migrator::migrations()
+            .iter()
+            .position(|migration| migration.name() == Migration.name())
+            .unwrap() as u32;
+        let Some(fixture) = PostgresTestSchema::migrated_through(
+            "postgres_cursor_index_fails_fast_while_delegation_is_locked",
+            Some(this),
+        )
+        .await
         else {
             return;
         };
         let db = &fixture.conn;
-        // Back to the state a node upgrading to this migration boots with.
-        crate::migrations::Migrator::down(db, Some(1))
-            .await
-            .unwrap();
         assert!(!recorded(db).await);
         let before = delegation_indexes(db).await;