fix: a stalled upload no longer wedges the bridge and kills idle-stop

[zcsizmadia]

Closes #435.

When the engine answers before the request body has finished forwarding, the connection is written off after a 250 ms grace:

engine.Close()
<-bodySent

The writer is bodySent <- req.Write(engine), and req.Write blocks on two things: it reads req.Body (which reads the client) and it writes to the engine. That teardown closes only the engine.

The covered case — engine answered early and stopped reading — already has a test. The other one did not: a client that stalls mid-upload parks req.Write in a Read that never returns, engine.Close() cannot touch a read, and <-bodySent waits forever.

Why a stalled client was allowed to kill a feature

rewriteBinds never returns → Server.handle never returns → s.clients.Add(-1) never runs:

• ActiveConns stays above zero for the life of the process. maybeIdleStop vetoes on "open client connections" forever — the idle-timeout feature is silently dead, with nothing in the log saying so. That is a README headline and the answer to the most common WSL2 complaint.
• Serve's wg.Wait() never completes, so shutdown hangs holding the single-instance lock — which the comment above Serve says must not happen. closeActive() would rescue it, and it runs only on shutdown, which is already blocked behind wg.Wait().

A laptop that sleeps during docker build. A dropped VPN. A killed CLI. No malice required.

The fix

abandonBody cuts both sides and bounds the wait:

• engine.Close() for the write stall, as before
• a read deadline in the past on the client conn — what actually reaches the read. resp.Close is already set, so the connection is finished either way and making it unreadable costs nothing.
• a bounded select, so the function returns even if the writer is wedged on something neither close reached. Leaking one goroutine costs a little memory; not returning disables idle-stop for every user of the process.

Verification

Negative control, run both ways:

	result
original two lines restored	hangs the full 30 s timeout and fails
with the fix	returns in 0.25 s

A second test pins the other direction — that the 5 s failsafe is not being waited out on the ordinary path, which would turn a correctness fix into a latency bug nobody attributed to it.

Not fixed here

#436 — the 101-upgrade path sharing clientR with the still-live body writer. Same 250 ms branch, different failure, and the two are ordered: joining the writer before relayBuffered is one of the candidate fixes there, and doing it first would have reintroduced exactly this hang.