Dedupe inflation promise per activeRequests session

[lejeunerenard]

Prior to the fix, the added test showed destroying stream a causing an error in stream b. This is because the tree node would cache the inflating promise which then made requests shared across streams or other contexts.

This fix tried to maintain the caching as much as possible from #60 (where the inflating promise caching came from) by separating by activeRequests session. That keeps the sessions isolated. The original intent of #60 still needs to factored in however.

Made with help from AI.

[caolan-tether]

This is particularly thorny because inflation can generate new requests using the current config. When we piggyback on an existing 'session' (i.e. config) to avoid duplicate work, we are waiting on requests made under a different config. An attempt to inflate a block with timeout: 10_000 followed by an attempt with timeout: 10 would risk waiting 10 seconds instead of 10 ms for the inflate request.

Hypercore's replicator itself handles varying concurrent timeouts correctly, but for that to work, each 'session' needs to make it's own requests via Hypercore (which also means each session needs to perform its own inflate as it might generate nested requests). That would make efforts to deduplicate inflation requests inside hyperbee2 very difficult.

I don't think piggybacking on another session can be done correctly and instead hyperbee2's inflate should step in to manage its own activeRequests to hypercore. If it owns the requests, it could potentially implement similar timeout handling to hypercore for downstream users of hyperbee2 - though this would be non-trivial and might require retry logic. This complexity might be avoided by removing the option to set a 'session' based timeout and to use a fixed timeout per hyperbee2 instance instead. This would make request sharing possible with a refcount for cancellation. I don't know if losing per-session or per-request timeouts is practical for downstream users, however.

If hyperbee2 did own activeRequests internally, I'd propose hyperbee2 implement an AbortController + AbortSignal based API for inflate cancellation.