[Flight] Add fuzz test for async debug info - #37129

I wanted to tweak some things there but I'm nervous without more coverage so I thought why not add a fuzzer.

So I asked Claude to build me one.

This adds a fuzzer for the async debug info tracking, seeded like our other fuzzers. Each seed builds a random Flight tree: components awaiting some data, cache(), waterfalls, Promise.all, promise props, elements rendered by a different component than created them (sometimes deduped across two locations), data preloaded before the request; some seeds abort, throw in a subtree, or interleave two renders; there are also a few userland thenables and Promise subclasses. The debug info is checked against what each seed's program actually did.

Details

• Each leaf does real I/O (a timer or an fs read) because IO entries only come from real async resources. To keep this deterministic, the driver first waits for everything the render has scheduled to finish, then runs the leaf's I/O while nothing else is pending, then resolves the leaf — so how long the I/O takes can't change what order anything runs in.
• The generator records which component created each element and invoked each data source, which real IO backs each leaf and what it resolves to, and the driver records the order it settled things in. The emitted debug info has to agree:
  • Owner chains equal the recorded creator chains, all the way up. When two renders run at once, debug info from one render never claims a component or IO from the other — that would mean the tracking mixed up which request an operation belonged to.
  • Recorded values equal what the leaf resolved to (values over the 1MB limit arrive as the omission placeholder).
  • An IO backed by a timer never carries a file-reading stack, and vice versa.
  • IO end times are ordered the way the driver settled things.
  • Every leaf a component directly fetched and settled shows up in that render's debug info. The exceptions are enumerated in the test with reasons (combinators only attribute the IO that unblocked them, promise props dedupe into the parent's await, and so on).
  • The same IO appears at most once per awaiting component, so accumulation fails immediately.
  • Time rows are monotonic, IO never ends before it starts, and IO with a stack has a name.
• We record performance.measure and check that every span has finite bounds, non-negative width, and a track.
• The fuzzer runs in prod too, but without the checks, to catch crashes.

Follow-ups

Found when running this:

• In DEV, calling .then() without a rejection handler on a chunk that holds a rejected value causes an unhandled rejection that can't be caught anywhere. Debug info for caught rejections hits this on most seeds. The first commit fixes our test util's instance, but the proper fix is TODO.
• I/O started with fs.readFile (callback form) before the request is attributed one stack frame too deep, naming the IO entry after the wrong frame. Fixed in the PR stacked on this one.
• An element prop that throws on unexpected property access (like a ClientReference proxy) corrupts the component's data chunk on the client. TODO.

These are fixed in #37130.