Conflicts resolved keeping main's single-bracket symbol naming and this
branch's synchronous pull completion (which also removes the now-unused
resolvedPromise() helper).

#35788)

Follow-up to #35786. Even with the synchronous-completion sentinel from
that PR, every synchronously-completing internal pull still paid one
promise reaction per pull just to flip `pulling` back to false a
microtask later. This runs those upon-fulfillment steps synchronously
instead: clear the flag, and if pullAgain was set during the pull,
recurse into callPullIfNeeded, which re-checks shouldCallPull exactly
like the async reaction would. Termination is guaranteed by the internal
algorithms' own re-entry guards (the tee reading flag, closeRequested on
one-shot sources). The now-unused shared resolved promise helper is
removed.

The observable difference is that a subsequent pull can begin in the
same synchronous segment instead of one microtask later. WPT streams
(153 passed, 0 failed, 4 expected failures, identical to baseline) and
fetch/api/response (54 passed) show this is not distinguishable by the
spec's ordering tests.

Benchmark (M1 Max, release build, 1000 chunks/stream):

| scenario | before | after | change |
|---|---|---|---|
| tee + drain both branches | 391 ns/chunk | 348 ns/chunk | -11% |
| drain, no tee | 155 ns/chunk | 152 ns/chunk | -2% |
| byte tee + drain both | 1390 ns/chunk | 1341 ns/chunk | -4% |

Towards #35768, #35771

…tent read request (#35790)

Follow-up to #35786 and #35788. The slow path of
readableStreamCollectIntoUint8Array, which backs every Body consumer for
JS-source streams (.bytes(), .text(), .json(), .arrayBuffer(), Blob),
looped over reader.read() and paid a Deferred, a read request instance,
a {value, done} result object, and an await microtask hop per chunk.

It now pumps with one persistent read request: synchronously available
chunks are delivered re-entrantly and re-armed in a do/while at constant
stack depth with zero microtask hops, and asynchronous chunks re-enter
the pump paying only the source's own pull reaction hop. Error and close
semantics are unchanged, including the TypeError on non-Uint8Array
chunks.

Benchmark (M1 Max, release build):

| scenario | before | after |
|---|---|---|
| .bytes(), 1KB chunks | 791 ns/chunk | 657 ns/chunk |
| same, equivalent userland read loop | 774 ns/chunk | 700 ns/chunk |

The consumer previously trailed a hand-written reader.read() loop over
the same stream; it now beats it. WPT streams (153 passed, 0 failed, 4
expected failures, identical to baseline), fetch/api/response (54), and
fetch/api/body (4) are green.

Towards #35768

Addresses the remaining generic-`pipeTo` work from #35768 (the
read-request reuse, pull-reaction, and identity-bypass items already landed in
#35786, #35788, #35790, #35799).

Towards #35768