fix(TCrossHttpClient): retry once on stale reused keep-alive connection

[freitasjca]

Problem

TCrossHttpClient surfaces a 400 to the caller when a reused pooled connection goes stale between requests. The stale keep-alive race is inherent in connection pooling: the server closes the connection; the client's write still succeeds locally (TCP send buffer), then the next read returns an error. Every mainstream HTTP client — WinHTTP, curl, Go net/http — retries transparently.

Solution

In TCrossHttpClientConnection.TriggerResponseFailed, detect the stale-connection case and re-dispatch the request once through TServerDock.DoRequest on a fresh connection.

Gates (all required):

• Not in Destroy teardown (FNoRetry) — avoids touching freed dock state
• Not already retried (FRetried) — bounded to one retry per request
• Body replayable: pointer+size or none (TBytes/TCustomMemoryStream qualify; chunk-source TStream closures do not)
• AND one of:
  • (a) dispatch rode a reused idle connection (FViaReusedConnection) and zero response bytes received (FRespDataReceived=False) — stale keep-alive race, safe for any method including POST
  • (b) method is idempotent (GET/HEAD/PUT/DELETE/OPTIONS) — RFC 7230 §6.3.1 explicitly permits automatic retry

Design choices:

• Forces a fresh connect on retry (TServerDock.DoRequest skips GetIdleConnection when FRetried): under concurrent bursts every idle pooled connection goes stale together, so retrying on another idle connection fails again.
• 50 ms pause on a throwaway thread — never blocks the IO thread; an immediate retry dies in the same backend transient that killed the first attempt.

Testing

Validated against fphttpserver (which closes keep-alive connections as a group on server-side restart/reload), eliminating flaky failures on HEAD (test 07) and concurrent requests (tests 18 and 29) in a 101-check suite run with TCrossHttpClient.