uWS HTTP path silently ignores keepAliveTimeout, timeout and headersTimeout

On the uWS HTTP path, `keepAliveTimeout`, `timeout` and `headersTimeout` are all silently ignored —
configured values are accepted and have no effect, so connections that would time out under the Node
HTTP server never do.

## Mechanism (harper, `server/http.ts` on `origin/main`)

The `HARPER_UWS_HTTP` branch (guard at ~`:601`, `process.env.HARPER_UWS_HTTP && !secure && !isOperationsServer…`)
builds `uwsServeConfigs[port]` and then `return httpServers[port];` at ~`:615`.

`keepAliveTimeout` (~`:619`), `requestTimeout`/`timeout` (~`:620`) and `headersTimeout` (~`:621`) are
read only in the Node-`http`-server branch immediately **below** that return, which the uWS path
never reaches.

`requestQueueLimit` **is** read and threaded into the uWS handler at ~`:611`
(`env.get(serverPrefix + '_requestQueueLimit')` → `makeUwsHandler`), which is what makes this look
like an oversight rather than a deliberate opt-out: one of the four knobs was wired, three were left
behind the early return.

No commit has touched this region since the gap was first observed (2026-07-25).

## Impact

Slow-loris-shaped connections (headers never completed, idle keep-alive sockets) have no deadline on
the uWS path. Relevance is rising now that harper-pro #609 bundles uWS in official images, though it
still requires `HARPER_UWS_HTTP` on a non-secure, non-operations server.

Related but distinct: #1752 covers three other uWS gaps (onUpgrade auth, Fastify-delegate IP
spoofing, static-buffering OOM) and does not mention timeouts.

## Fix shape

Read the three options before the uWS early return and thread them into the uWS server config the
same way `requestQueueLimit` already is; if uWS genuinely cannot honor one of them, log at startup
that the configured value is inert rather than accepting it silently.

Start in server/http.ts at the HARPER_UWS_HTTP branch around lines 601-621 and compare its uWS configuration with the Node http-server branch below the early return. Trace how requestQueueLimit reaches makeUwsHandler, then determine how the three timeout options can be handled in the uWS configuration. Done means configured values no longer remain silently inert, or startup clearly reports when uWS cannot honor one.

Written by the indexing model from the issue text.