the_json_listing_migrates_the_cache_and_the_table_does_not flakes on a full-suite run

[blooop]

Found by the fresh-context review of #514, which correctly identified it as pre-existing and unrelated to that diff. Filing it so it is not carried in a PR thread.

rust/dl/tests/read_side.rs:748 the_json_listing_migrates_the_cache_and_the_table_does_not fails roughly one full-suite run in five and passes in isolation.

The mechanism the reviewer traced: --ls is in CACHE_READING_COMMANDS (flows/completion_cache.rs:209), so it spawns a background dl --update-cache. That child calls open_records, open_records runs the cache migration, and the migration races the assertion that the document is still at version 1. The test is asserting that the table path does not migrate, and a detached child of its own making does.

So the flake is not timing noise around an unrelated write. It is the test racing a process the command under test started, which means the fix is about what the test does with that child rather than about widening a tolerance.

Worth doing alongside #416, which carries the residual aid pty flakes: same class of problem, and the same question of whether a test that spawns a real child should be waiting on it.

[blooop]

Second flake in the same family, and a cheap discriminator for the next one

a_warm_triple_launch_does_no_metadata_io_at_all (rust/dl/tests/launch.rs:467)
failed once on PR #506 and passed on rerun, same commit, no change in between:

thread 'a_warm_triple_launch_does_no_metadata_io_at_all' panicked at dl/tests/launch.rs:467:78:
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound }

Line 467 is the read_to_string of the seeded corrupt metadata.json, so the
file the test wrote at the start was absent by the time it read it back.

What makes it clearly a flake rather than a defect, and the check is worth
reusing: the failure was in rust-coverage, and on the identical head SHA
ff8f91c the rust job passed the same suite twice, once as its named
Test dl launch step and once inside cargo test --workspace (the backstop
#505 added). Same commit, same test, three runs, one failure, and the only one
that failed was under llvm-cov instrumentation.

So the discriminator is: compare the two jobs on the same SHA before
investigating. If rust passed the suite that rust-coverage failed, the
difference is the instrumentation, not the code. That is a ten-second query and
it replaced what would otherwise have been a hunt through a diff that touches
neither the test nor anything it exercises (#506 changes --force argument
placement).

Note the backstop earned its keep immediately here: having the suite run twice in
one job is what made "passed twice, failed once" observable at all. Before #505
there was one run per suite and no way to tell a flake from a break without a
rerun.

Filing beside #526 rather than as its own issue because the two are plausibly one
thing: both are timing-sensitive tests in dl's process-level suites that fail
under load and pass in isolation. If they turn out to have separate causes this
can be split out.