Fix two ways a grpctunnel goroutine could outlive its test and panic the package

[shawnburke]

Symptom

go test -race ./server/grpctunnel/ failed intermittently, about once in twenty runs when other packages ran alongside it, with the package finishing faster than a passing run. Reproduced on clean main with the full log captured:

panic: Log in goroutine after TestCall_ServerCancelAbortsBackend has completed:
  ERROR  grpc-tunnel  Call execution failed  {"callId": "c1", ..., "error": "context canceled"}
    call_handler.go:235

A goroutine logging through zaptest after its test has returned is a panic, and a panic ends the package run early.

Root cause (commit 1)

handleCallFrame removed a call from the call table as soon as the server's Cancel frame arrived, while the call goroutine was still unwinding the backend and had its error and completion log lines left to write. The table is what the heartbeat check and the test barrier in newTestCallTable use to mean "a call goroutine is still running", so the barrier saw an empty table, the test returned, and the goroutine's log landed on a finished test.

The cancel path now cancels and closes the body but leaves removal to the goroutine's own defer, as every other path already did. TestCall_ServerCancelKeepsCallInTableUntilGoroutineExits pins the invariant and fails deterministically against the old code.

TestCall_ServerCancelAbortsBackend × 400 under -race	before	after
panics	1	0

Same class, found while looking (commit 2)

Start ran startAsync on a goroutine outside the wait group, so Close could return with registration, worker startup and the "gRPC tunnel started" log line still to happen. Looping Start and Close under -race hit it within the first couple of iterations. startAsync is now counted in the wait group; its registration loop and the loops it launches already exit on the parent context, so a Close during startup still returns promptly. TestStartThenClose_WaitsForStartup covers it.

Verification

• make -C agent test and make -C agent test-race pass.
• Five further runs of the four-package -race invocation that originally failed: grpctunnel ok every time.
• Not changed here: grpctunnel is still not in RACE_CLEAN_PKGS. It has been clean across every race run on this branch, so promoting it is a reasonable follow-up once this has soaked.

🤖 Generated with Claude Code