fix(ci): remove Detect Changed Paths timeout and deletion test race (#8300)

🤖
## Summary
This PR removes two CI flakes that failed relay-stack runs on
2026-10-13. Both passed when rerun.

- **Detect Changed Paths timeout.** This first CI job had a 2-minute
limit. Its steps take about 75 seconds, but GitHub sometimes finishes
the job minutes after the last step. In three runs, every step had
finished, but GitHub still cancelled the job at the limit, and all later
jobs failed. The limit is now 10 minutes.
- **PostgreSQL deletion test.**
`approval_boundary_blocks_claim_until_exact_inventory_is_approved`
sometimes could not claim an approved deletion request. This was a race
in the test, not a product bug.

How the test race happens:
- The test sends an UPDATE that the database must reject. Then it claims
the same row. PostgreSQL sends the error to the client before it rolls
back the statement and releases its row lock. sqlx returns as soon as it
gets the error.
- The claim runs on another pooled connection with `FOR UPDATE ... SKIP
LOCKED`. It can skip the row while the lock is still held, and return no
claim.
- The test now runs the rejected UPDATE on its own connection. Then it
sends `SELECT 1` on that connection before it claims. That round trip
completes only after PostgreSQL has finished the rollback.

Production code does not change. A claim that skips a row locked by
another transaction is correct behavior. I checked the other tests in
this file. Only this test has a rejected write on the request row
immediately before a `SKIP LOCKED` claim. In the other tests, a blocking
`approve` call runs before the claim.

### Related issue
N/A. No existing PR found. Failing runs: [timeout
#8174](https://github.com/block/buzz/actions/runs/38468285648/job/115540525751),
[timeout
#8176](https://github.com/block/buzz/actions/runs/38468321774/job/115541550557),
[timeout
#8182](https://github.com/block/buzz/actions/runs/38468329504/job/115541197994),
[deletion test
#8182](https://github.com/block/buzz/actions/runs/38468329504/job/115550003726).

### Testing
- I confirmed the order in the PostgreSQL 17 source: `EmitErrorReport()`
(which flushes to the client) runs before `AbortCurrentTransaction()` in
`tcop/postgres.c`. A BEFORE UPDATE trigger locks the row first
(`GetTupleForTrigger` in `commands/trigger.c`).
- I could not reproduce the failure locally: 0 failures in 410 runs,
including runs on a CPU-limited PostgreSQL container. The fixed test
passes against PostgreSQL 17.

Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>

crates/buzz-db/src/store/deletion.rs

@@ -6304,17 +6304,27 @@ mod postgres_tests {
             mismatched_approval.is_err(),
             "approval digest must remain database-bound to the frozen request digest"
         );
+        // PostgreSQL sends this rejection before it rolls the statement back
+        // and releases the request row lock, and sqlx returns on the error.
+        // The claim below uses SKIP LOCKED on another pooled connection, so
+        // finish a round trip on this connection before claiming.
+        let mut tamper_conn = db.pool.acquire().await.expect("acquire tamper connection");
         let mismatched_request = sqlx::query(
             "UPDATE community_deletion_requests SET inventory_digest = $2 WHERE id = $1",
         )
         .bind(request.id)
         .bind(vec![1_u8; 32])
-        .execute(&db.pool)
+        .execute(&mut *tamper_conn)
         .await;
         assert!(
             mismatched_request.is_err(),
             "the frozen request digest must remain bound to its approval"
         );
+        sqlx::query("SELECT 1")
+            .execute(&mut *tamper_conn)
+            .await
+            .expect("rejected update has rolled back");
+        drop(tamper_conn);
         assert!(store
             .claim_specific(request.id, "executor-a", DEFAULT_LEASE_DURATION)
             .await