fix(web): reap the shutdown goroutine when Start fails to bind

[xunholy]

Bug

Server.Start spawns a goroutine that blocks on the caller's context until shutdown, then calls srv.Shutdown. It waited on the caller's ctx directly — but Start has an early-return path: when srv.ListenAndServe returns a non-ErrServerClosed error (the common case being a bind failure, address already in use), Start returns that error without cancelling ctx. The shutdown goroutine is then stuck on <-ctx.Done() forever (until the caller eventually cancels its context — which on an error return it may never do). Every failed bind leaks one goroutine.

Fix

Derive a cancellable context (runCtx) from the caller's ctx with a deferred cancel, and have the goroutine wait on runCtx:

runCtx, cancelRun := context.WithCancel(ctx)
defer cancelRun()
go func() { <-runCtx.Done(); /* srv.Shutdown */ }()

Now the goroutine is reaped on every return path:

• bind-error path — the deferred cancelRun wakes it (srv.Shutdown on a server that never served is a no-op)
• normal path — the caller's ctx cancellation still propagates through runCtx exactly as before, so graceful shutdown is unchanged

Verification

Regression test mirrors the runtime.NumGoroutine before/after pattern already used in internal/agent/streaming_test.go: occupy a loopback port, call Start on it so ListenAndServe fails to bind, and assert — with the caller's ctx left uncancelled — that the goroutine count returns to baseline.

Red→green proven: fails on pre-fix code (2 → 3 goroutines, one never reaped), passes after the fix (reaped in ~0.07s).

• gofmt / go vet clean
• golangci-lint run ./... → 0 issues
• go test -race ./internal/web/ → ok