wgengine/netstack: fix data race on in-flight connection test globals

The maxInFlightConnectionAttemptsForTest and
maxInFlightConnectionAttemptsPerClientForTest globals were plain ints
read by background gVisor TCP handler goroutines (via
wrapTCPProtocolHandler) and written by tstest.Replace cleanup in
TestTCPForwardLimits_PerClient. When a gVisor goroutine outlived the
test cleanup window, the race detector caught the unsynchronized
access.

The race-prone code was introduced in c5abbcd4b4 (2024-02-26,
"wgengine/netstack: add a per-client limit for in-flight TCP
forwards") which added both the plain int globals and the
TestTCPForwardLimits_PerClient test that writes them via
tstest.Replace. It is not obvious why this has only recently started
being detected as a data race; likely some combination of gVisor
version bumps, Go toolchain scheduler changes, and additional
TCP-injecting subtests (e.g. 03461ea7f, 2026-01-30) increased
goroutine churn enough to hit the window.

Change both globals to atomic.Int32 and replace tstest.Replace (which
does non-atomic *target = old on cleanup) with explicit Store/Cleanup
pairs.

Fixes #19118

Change-Id: Id26ba6fbfb2e4ade319976db80af8e16c7c8778e
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>

wgengine/netstack/netstack_test.go

@@ -814,8 +814,10 @@ func TestTCPForwardLimits_PerClient(t *testing.T) {
 	envknob.Setenv("TS_DEBUG_NETSTACK", "true")
 
 	// Set our test override limits during this test.
-	tstest.Replace(t, &maxInFlightConnectionAttemptsForTest, 2)
-	tstest.Replace(t, &maxInFlightConnectionAttemptsPerClientForTest, 1)
+	maxInFlightConnectionAttemptsForTest.Store(2)
+	t.Cleanup(func() { maxInFlightConnectionAttemptsForTest.Store(0) })
+	maxInFlightConnectionAttemptsPerClientForTest.Store(1)
+	t.Cleanup(func() { maxInFlightConnectionAttemptsPerClientForTest.Store(0) })
 
 	impl := makeNetstack(t, func(impl *Impl) {
 		impl.ProcessSubnets = true