fix(http2): ignore PRIORITY and unknown frames on streams and reject non-zero stream control frames - #2006

…th unconsumed data

> [!NOTE]
> This PR was generated by an AI coding agent (Jetski) on behalf of @mosuem.

### Summary

Per **RFC 9113 Section 5.2 (Flow Control)** and **Section 6.9 (`WINDOW_UPDATE`)**, a receiver that receives a flow-controlled `DATA` frame must always account for its contribution against the connection flow-control window, even when the stream terminates abnormally or its incoming messages are discarded before the application consumes them.

Previously:
1. `ConnectionMessageQueueIn.removeStreamMessageQueue(streamId)` discarded buffered `DataMessage`s in `_stream2pendingMessages[streamId]` without calling `_windowUpdateHandler.dataProcessed(ignoredBytes)`. If a stream was paused (or had not yet been listened to) when `DATA` frames arrived and was subsequently terminated (`stream.terminate()` or `RST_STREAM`), those bytes were permanently leaked from the connection-level receive window. Once 65,535 bytes (or `connectionWindowSize`) accumulated across terminated streams, all future streams on the connection deadlocked waiting for connection window credit.
2. `StreamMessageQueueIn.cancel()` only completed `_onCancelCompleter` without draining `_pendingMessages`, updating `bufferIndicator`, or running `onCloseCheck()`. Cancelling `stream.incomingMessages` while paused left `bufferIndicator.wouldBuffer == true`, stranding buffered `DATA` in `ConnectionMessageQueueIn` and keeping the stream's active slot open indefinitely.
3. `StreamHandler._terminateStream` was a no-op when `stream.state == StreamState.Closed`, so calling `stream.terminate()` on a stream whose remote end had already sent `END_STREAM` while the local listener was paused failed to clean up the stream or replenish the connection window.

### Changes
- **`lib/src/flowcontrol/connection_queues.dart`**: In `ConnectionMessageQueueIn.removeStreamMessageQueue`, sum the byte lengths of any undelivered `DataMessage`s and call `_windowUpdateHandler.dataProcessed(ignoredBytes)` when `!wasTerminated`. Also terminate any remaining stream message queues in `ConnectionMessageQueueIn.onTerminated`.
- **`lib/src/flowcontrol/stream_queues.dart`**: Override `StreamMessageQueueIn.cancel()` to drain `_pendingMessages`, update `bufferIndicator` so `ConnectionMessageQueueIn` flushes any held messages and replenishes the connection window, and run `onCloseCheck()`.
- **`lib/src/streams/stream_handler.dart`**: Allow `_terminateStream` to clean up `StreamState.Closed` streams whose `incomingQueue` has not yet closed.

### Test Verification (Fails Before $\rightarrow$ Passes After)

Added two regression tests in `test/flow_control_test.dart`, driving the raw peer from #1999:
- `terminating a stream with unconsumed buffered DATA replenishes the connection receive window`
- `cancelling incomingMessages on a paused stream replenishes the connection window and releases the active stream slot`

Wherever a test needs to know that the client has processed the frames sent so far (or finished reacting to a cancel), it uses the peer's PING round trip (`peer.barrier()`) rather than a wall-clock sleep.

**Before fix** (tests on `master`):
```text
00:05 +0 -1: terminating a stream with unconsumed buffered DATA replenishes the connection receive window [E]
  TimeoutException after 0:00:05.000000: Future not completed
  test/flow_control_test.dart 126:7  _RawPeer.until
  test/flow_control_test.dart 427:5  main.<fn>
00:10 +0 -2: cancelling incomingMessages on a paused stream replenishes the connection window and releases the active stream slot [E]
  TimeoutException after 0:00:05.000000: Future not completed
  test/flow_control_test.dart 126:7  _RawPeer.until
  test/flow_control_test.dart 469:5  main.<fn>
```

**After fix:**
```text
00:00 +9: All tests passed!
```

…ity-unknown-and-control-frames

# Conflicts:
#	pkgs/http2/CHANGELOG.md