Add directional tests for control characters in the request line

### Motivation

A request-smuggling class of vulnerability exists when HTTP parsers silently strip boundary control bytes (NUL, CR, LF, VT, FF) from the version token before matching — see [netty/netty#16970](https://github.com/netty/netty/issues/16970).

Pekko HTTP uses a fundamentally different parsing strategy — byte-by-byte exact matching at fixed offsets in `HttpMessageParser.parseProtocol` (`HttpMessageParser.scala:130-140`) with no `trim()` or whitespace/control-character stripping. Analysis confirms that Pekko HTTP is **not affected** by this vulnerability: the NUL byte is consumed into the URI by `parseRequestTarget` and rejected by the URI parser before the version token is ever reached.

However, no existing test in `RequestParserSpec` exercises this code path with control characters. A directional test should be added to lock in this behavior and prevent regressions from future parsing refactors.

### Modification

Add directional test cases to `RequestParserSpec` that verify control characters (NUL) in the request line are rejected with an appropriate error status.

### Result

The test suite will explicitly cover the control-character-in-request-line scenario, ensuring that Pekko HTTP continues to reject such malformed requests and that any future parsing changes do not introduce a trim-based vulnerability.

### References

- Netty issue: https://github.com/netty/netty/issues/16970

Start in RequestParserSpec and inspect HttpMessageParser.parseProtocol at HttpMessageParser.scala:130-140, along with parseRequestTarget. Add directional cases for a NUL in the request line and verify the malformed request is rejected with an appropriate error status. Run the relevant RequestParserSpec to confirm the behavior.

Written by the indexing model from the issue text.