db_bounded polls the future when the deadline is already spent, making discovery_record_elapsed_leaves_neither_row flaky #585

What happened?

db_bounded (crates/gitlawb-node/src/ipfs_pin.rs:185) wraps the future in tokio::time::timeout(left, fut). With left == 0, tokio still polls the inner future first (tokio 1.54.1, time/timeout.rs:216), so a spent deadline can return a value instead of BoundedDbError::Elapsed. A test with a future that is ready on its first poll shows it deterministically:

a spent deadline must yield the timeout arm even for a ready future: Ok(7)

ipfs_pin::tests::discovery_record_elapsed_leaves_neither_row goes through the same path with a DB write. It failed in CI on test (beta) for #196 with a spent deadline must yield the timeout arm, not a value: Ok(()).

Impact is on the test. db_record_deadline floors the budget, so the spent-deadline branch is close to unreachable in production.

Expected behavior

A spent deadline returns Elapsed without starting the work, as the helper's docs and db_bounded_elapsed_deadline_errors_promptly describe.

Steps to reproduce

Run cargo test -p gitlawb-node --lib -- discovery_record_elapsed_leaves_neither_row repeatedly on main at 6f990197. It failed 10 of 60 runs on an idle 4-core machine and 46 of 60 with 8 CPU-bound busy loops running. Inside the full suite it fails less often, mostly under CI load.

Affected crate

gitlawb-node

Version or commit

6f990197

Notes

• That the DB write completes within the first poll is inferred, not proven. The ready-future test proves only the poll-first behavior.
• This is separate from the red main in CI is red on main #584. That run failed reconciliation::tests::sweep_persists_last_attempted_not_planned_tail_on_mid_batch_narrow, which has not been reproduced here.
• Proposed fix: return Elapsed before polling when no budget remains, checked by rerunning the loaded repro after the change.