fix(test): expect legacy-abort deprecation warning in request_signal_streaming

[divybot]

Problem

test specs ... serve::request_signal_streaming is currently failing on every main commit since #34397 landed. Example: it fails on the latest main (69de4f41e4) and on the 6 commits before it, back to #34397 itself.

This is a semantic merge conflict between two PRs that landed in parallel:

• fix(http): handle raw h1 serve regressions #35049 added the serve/request_signal_streaming spec test, whose main.out expects only the program output.
• feat(ext/http): deprecation warning for legacy request abort #34397 added a deprecation warning that fires when a handler uses legacy abort, accesses request.signal, and the request completes successfully.

The test exercises exactly that scenario (it reads req.signal.aborted and adds an abort listener, then returns a successful streaming response), so the new warning is now printed to stderr and the captured output no longer matches main.out. Neither PR's CI saw the other's change.

Fix

The warning is correct and intended for this case, so update the test's expected output to include it. The warning is emitted deterministically as the first line (verified across repeated runs).

+Deno.serve: request.signal aborts on successful responses (legacy behavior, ...). ...
 body: chunk1;chunk2;chunk3;chunk4;chunk5;
 aborted during stream: false
 aborted after completion: true

Verification

cargo test --test specs -- serve::request_signal_streaming
test specs::serve::request_signal_streaming ... ok

This unblocks test specs (…) debug for all open PRs (it currently fails for every PR that merges with main).

[divybot]

Folding this into #35133 (the publish PR) so that PR's CI is self-sufficient and doesn't have to wait on this one to merge first. The fix is identical — updating request_signal_streaming's expected output to include the legacy-abort deprecation warning. If you'd rather keep it standalone, I can reopen and drop it from #35133.