HTMLRewriter reports handled source-stream errors as uncaught

## Description

When an input `ReadableStream` errors while an `HTMLRewriter` output body is being consumed, handling the transformed body rejection does not prevent the source error from being reported as uncaught.

The C++ streams implementation logs the source error twice; the TypeScript streams implementation logs it once. These reports are user-visible in traces even though the `.text()` rejection was handled.

## Reproduction

PR #7178 adds `erroringSourceRejectsConsumption` in `src/tests/streams/htmlrewriter/rewrite-streams.js`:

```js
const boom = new Error("boom");
const rs = new ReadableStream({
start(controller) {
controller.enqueue(new TextEncoder().encode("

x"));
},
pull(controller) {
controller.error(boom);
},
});

await new HTMLRewriter().transform(new Response(rs)).text().catch(() => {});
```

The consumption rejection is handled, but workerd still reports `Error: boom` as uncaught twice with C++ streams and once with TypeScript streams.

## Expected behavior

Handling the transformed body rejection should prevent the source error from being reported as uncaught.

## Reference

[Review discussion](https://github.com/cloudflare/workerd/pull/7178#discussion_r3930141276)

Start with src/tests/streams/htmlrewriter/rewrite-streams.js and run the erroringSourceRejectsConsumption reproduction from PR #7178. Compare the C++ and TypeScript stream implementations to trace how the handled transformed-body rejection reaches uncaught-error reporting. Done means the source error is not reported as uncaught in either implementation and the regression test passes.

Written by the indexing model from the issue text.