fix(api): rewrite SSH tunnel HTTP requests over raw duplex stream

[DiogoDuart3]

What / why

tunnelRequest() in apps/api/src/lib/ssh-tunnel.ts used Node's http.request()
with a custom createConnection that returned the SSH tunnel's duplex stream
directly, instead of opening a real TCP socket.

Root cause

Under Bun's node:http polyfill, a caller-supplied createConnection is not
honored — http.request() still attempts to open its own connection under the
hood regardless of what createConnection returns. Every request made through
this path failed with ECONNREFUSED, which the existing req.on("error", ...)
handler quietly resolved to null.

This was caught on a real self-hosted install: analytics scraping for a remote
server reached over an SSH-tunnel executor consistently returned zero data,
even though the target service was healthy and reachable by every other check.
Tracing tunnelRequest() directly (bypassing the higher-level analytics code)
reproduced the ECONNREFUSED immediately.

Fix

Write the HTTP/1.1 request directly onto the tunnel's raw duplex stream and
parse the response by hand — status line, headers, Content-Length/chunked
transfer-encoding body framing, and a connection-close fallback for responses
with neither. This mirrors the approach this same file's tunnelStream()
already uses for streaming responses, so the file is now internally
consistent and no longer depends on node:http understanding a
non-standard socket.

Test plan

• tsc --noEmit on apps/api — clean.
• Verified directly against a live self-hosted install: before the fix,
  tunnelRequest() against a real SSH-tunneled service returned null on
  every call; after the fix, it returns the correct status/headers/body, and
  analytics scraping for that server started reporting real data again.
• No existing unit test file covers this module; the fix is a drop-in
  replacement of the request/response mechanics with the same public
  signature (tunnelRequest(...)) and return type, so no callers change.

[DiogoDuart3]

The failing Test check here is a pre-existing failure on main's own tip (currently 6a677363, e.g. run 30536159910) — @repo/dashboard#test fails identically with zero changes from this PR. Typecheck passes. None of this PR's files touch apps/dashboard.

[Hydralerne]

Confirmed the root cause independently: bun 1.3.3 ignores createConnection → ECONNREFUSED, node 22 honours it → 200. Good find, and raw HTTP on the duplex is the right fix.

Two things to fix first — both re-create the silent-no-data symptom this PR is fixing:

1. transfer-encoding value isn't lowercased. Transfer-Encoding: Chunked and gzip, chunked both miss === "chunked". With no Content-Length it then falls to the close handler and returns raw chunk-framed bytes (1a4\r\n{…}) as the body with status 200 → the caller's JSON.parse throws.

const te = String(parsedHeaders["transfer-encoding"] ?? "").toLowerCase();
const isChunked = te.split(",").some((t) => t.trim() === "chunked");

2. The close fallback resolves success for a truncated response. If chunked never reached the 0 chunk, or Content-Length wasn't satisfied, it still returns a partial body as 200 — http.request surfaced that as an error → null. Hoist contentLength/isChunked out of the data handler and gate it:

if (headerEnd !== -1 && contentLength === null && !isChunked) finish({ … });
else finish(null);

3. (fine as a follow-up) This adds a second hand-rolled head parser — tunnelStream:188 has the same logic but with buffer += chunk.toString(), which corrupts multi-byte UTF-8 across chunk boundaries. One shared parseHttpHead() dedupes both and fixes that.

Nits: caller headers are appended after the computed ones, so a caller-passed Content-Length duplicates; no CRLF validation now that http.request isn't doing it (not reachable today — all callers encodeURIComponent); the comment mentions an end listener that isn't registered; a malformed chunk size returns null, so it hangs to timeout instead of failing fast.

Content-Length off the Buffer, the settled guard, and chunk-extension handling are all correct.