test(fpc): gate WebSocket EAGAIN regression

[freitasjca]

Summary

Adds an FPC + epoll WebSocket regression test for the EAGAIN handling fixed in #549 and runs it in GitHub Actions with FPC 3.2.2.

The test opens a real WebSocket connection over the epoll provider and verifies that:

1. the first EAGAIN does not resume the HTTP pipeline or emit a stray response;
2. an idle upgraded connection remains silent and open across multiple read ticks;
3. a frame sent after the idle period reaches OnMessage and is echoed;
4. an abrupt peer close releases the read loop and the server continues serving HTTP.

Review adjustments

The maintainer follow-up commit makes the original contribution CI-ready:

• wires the regression runner into .github/workflows/tests.yml;
• binds the server to 127.0.0.1;
• handles partial socket writes;
• accumulates complete HTTP headers and bodies across multiple recv calls;
• captures errno once before classifying EAGAIN/EWOULDBLOCK;
• enables fail-fast shell behavior;
• removes the duplicate Pascal keep-alive test, retaining the existing FPCHttpKeepAliveServer.dpr + fpc_keepalive_regression.py pair as the authoritative keep-alive regression gate.

Validation

• updated test against current code: 5 passed, 0 failed;
• control run against commit 37d699f (before the WebSocket fix): 2 passed, 3 failed, detecting the stray HTTP response, idle-connection violation, and missing echo;
• workflow validated with actionlint.

[regyssilveira]

Thank you for adding coverage for these FPC-specific paths. The WebSocket regression test was compiled and run with FPC 3.2.2 in Docker and all 5 checks passed.

Before merging, could you please address the following points?

1. Wire the new tests into GitHub Actions. As submitted, neither program runs automatically, so they do not yet act as regression gates.
2. Please revisit the keep-alive timing assertion. Requiring every one of 30 requests to complete within 35 ms is vulnerable to unrelated runner scheduling spikes. The existing Python regression test ignores connection setup and evaluates steady-state median latency; the Pascal test should use a similarly robust criterion, or replace/consolidate the existing test rather than duplicate it.
3. In the WebSocket test, read the HTTP response until the complete headers and declared body have arrived. A single recv is allowed to return a partial response and can make the final /ping assertion flaky.
4. Bind the test server explicitly to 127.0.0.1 instead of all interfaces.
5. Please clarify the intended role of FPCHttpKeepaliveTest.dpr relative to the existing FPCHttpKeepAliveServer.dpr + fpc_keepalive_regression.py pair. Keeping one authoritative CI path will reduce maintenance and contradictory thresholds.

Issue #565 identifies a separate Windows/FPC gap: keep-alive is enabled there, while the TCP_NODELAY socket handler is currently Unix-only. We will handle that implementation separately, but Windows CI coverage for the resulting behavior would be welcome either here or in a follow-up.

[regyssilveira]

Validated after the maintainer follow-up: 5/5 checks pass on FPC 3.2.2 in Docker, the pre-fix control fails the three expected assertions, and the workflow passes actionlint. The duplicate keep-alive test was removed in favor of the existing authoritative CI regression.