Example of the old bug:

1. Request A starts. It does: Blob.pushScope exeState
   Stack:
   [ scopeA ] <- top

2. Request B starts before A finishes. It also does: Blob.pushScope exeState
   Stack:
   [ scopeB ] <- top
   [ scopeA ]

3. Request A creates an ephemeral blob.
   The old code did not remember "the scope that belongs to Request A." Instead, it always attached new blobs to whatever scope was currently on top of the shared stack. But Request B had already started, so B's scope was now on top. That means A's blob was accidentally registered under B’s scope.
   scopeB tracks idA // wrong
   scopeA tracks nothing

4. Request B finishes first.
   Blob.popScope exeState This pops scopeB and deletes every blob ID tracked by it. That deletes idA, even though Request A is still running. blobStore no longer has idA

5. Request A later tries to read or promote its blob. But idA was deleted when B finished, so it fails with: ephemeral blob not found

The core issue was that concurrent requests shared one ExecutionState.blobScopes stack. A stack only works if scopes exit in exact last-in-first-out order.
Concurrent HTTP requests don't guarantee that, so one request could accidentally put its blob into another request's top scope.

After:
DBlob(Ephemeral { id; bytes }) carries the bytes directly inside the value. So as long as the Dval exists, the bytes exist. There is no shared ephemeral store and no UUID lookup that can go stale.