Parser: handle HTTP 103 Early Hints

[Elgeryy1]

Summary

• Skip HTTP 103 Early Hints header blocks and parse the following final response.
• Keep bodyless final responses, such as HTTP 308 redirects, valid.
• Reject a response stream that ends after an interim 103 response.
• Add focused parser coverage for these cases.

Why

cURL can expose HTTP 103 headers before the final feed response. Previously the parser treated the 103 headers as the response and the actual status line as body data.

References FreshRSS/FreshRSS#7408.

Testing

• phpunit --no-configuration --bootstrap autoloader.php tests/Unit/HTTP/ParserTest.php (25 tests, 129 assertions)
• PHP syntax checks for the changed source and test files

[Alkarex]

Would you be able to compare with simplepie#976 ?

[Elgeryy1]

Compared with simplepie#976. The core state-machine change is the same: after a 103 header block, reset the response metadata and parse the following status line.

I kept this implementation because it also covers two edge cases that simplepie#976 does not:

• It accepts a bodyless final response (for example, a 308 redirect) after one or more 103 responses.
• It rejects a stream that ends after only a 103 response. In Parser: Support HTTP Early Hints response simplepie/simplepie#976, parse() would report that input as successful because status 103 is non-zero.

The tests in this PR explicitly cover both cases, in addition to the normal 103 -> 200 path. I do not think a code change is needed after the comparison.

[Elgeryy1]

Compared with simplepie#976. Both use the same �ody_or_status state-machine approach, but this PR additionally covers two edge cases: a bodyless final 308 response is accepted, and a stream ending immediately after a 103 is rejected rather than accepted as a complete response. I kept the tests focused on those behavioral cases. If you prefer the upstream patch as the base, I can adapt this PR to it; otherwise the two fixes are compatible in intent.