daemon: fold activeClusterTransport under the comms epoch guard

[psaab]

activeClusterTransport was written by startClusterComms holding neither clusterCommsMu nor applySem, and read by applyTailReconciles step 20 under applySem.

The issue's "NOT a race today" is wrong

#6290 reasoned that the boot startClusterComms completes before the gRPC/HTTP servers accept commits, so the write is visible before any reader. That accounts for the wrong readers — applyConfig's own doc lists DHCP callbacks, config-poll, dynamic feeds, event engine, in-process CLI commits, CLI auto-rollback, cluster sync recv, none of which are the gRPC or HTTP servers.

The DHCP one is live before the write:

daemon_run_bringup.go  dhcp.New(..., d.onDHCPAddressChange, ...)   callback wired
daemon_run_bringup.go  boot d.applyConfig(cfg)
 -> daemon_apply_routing.go  reconcileDHCPClients(cfg)             client goroutines START
daemon_run.go          d.startClusterComms(ctx)                    the WRITE happens here

A lease arriving in that window runs onDHCPAddressChange → applyConfig → step 20, which reads the field. That goroutine was created before the write, so goroutine creation orders them the wrong way and supplies no happens-before; applySem cannot bridge it because a semaphore only excludes participants that take it, and the boot writer does not. This is the mirror of #5113 on mgmtVRFInterfaces — written under applySem, read by this same callback without it — which daemon.go already documents as "a real Go data race".

Fix

setActiveTransportIfCurrent(gen, key), epoch-gated like publishSessionSyncIfCurrent rather than a bare locked store: the same window admits two concurrent startClusterComms calls (boot + a DHCP-driven restart from step 20), and an ungated store lets the loser land last, leaving the transport key describing a superseded epoch while clusterCommsGen names the live one. Step 20 now takes ONE activeTransport() snapshot for its comparison and its eight log fields.

Validation

Both new tests PASS under go test -race -count=1. Two mutations, each binding its own guard:

• A — drop both mutex guards (master's exact shape) → WARNING: DATA RACE, write attributed to startClusterComms at daemon_ha_sync.go:706.
• B — drop the gen != check, keep the mutex → TestSetActiveTransportDropsStaleEpoch FAILS without -race, while the race test still passes.

Neither test is satisfied by the other's guard.

go test ./pkg/... ./cmd/... exit 0 (59 packages, zero failures). go test -race ./pkg/daemon/ exit 0. go vet, gofmt, go test ./pkg/refactoraudit/ clean.

Not done

make test-failover — the required cluster smoke for this path per pkg/daemon/README.md — was not run; the lead schedules cluster work.

Note: daemon_ha_sync.go is now 1499 lines, one under the refactor-audit 1500 threshold. The gate passes, but the next line added to this file trips it.

Closes #6290