Re-enable the -race unit-test CI job (disabled since #3147)

[neyy91]

The -race CI job has been off for ~2 years. I investigated why, found
the blockers are 3 small test-side data races (not production bugs), fixed them,
and verified the full unit suite now passes under -race. This issue tracks
landing those fixes and turning the job back on.

What happened

The unit-test race detector job was disabled in #3147 (Jan 2024), described there
as a temporary removal because it "intermittently fails across a handful of
tests". It's still commented out in .github/workflows/go-ci.yml today.

Why it matters

With -race off, data races merge unnoticed. Re-enabling it closes a ~2-year gap
and protects the codebase going forward — every PR gets checked automatically.

What I found

Ran the unit suite under -race locally, per-package: 36/41 packages already
clean. Every failure is test-side (shared fixtures/mocks or racy test code),
not a production bug:

1. share/eds + store/file — TestSuiteAccessor runs parallel subtests on a
   shared *rsmt2d.ExtendedDataSquare; rsmt2d caches row/col roots lazily without
   locking, so the parallel first-access races.
2. shrex_getter — the test shares one headertest.Subscriber mock between two
   managers that call NextHeader concurrently.
3. libs/utils — TestSessions_ConcurrentDifferentKeys updates a plain int from
   many goroutines (the Sessions implementation itself is correct).
4. api/client TestSubmission — not a race; an intermittent embedded-testnode
   failure ("nil block meta for height 2"), same framework as flaky: TestArchivalBlobSync in nodebuilder/tests #4958. Pre-existing
   flake, out of scope here.

What I propose

Land the three test fixes as small PRs (each reproduces the race under -race),
then flip the job back on:

• libs/utils: maxActive → atomic
• shrex_getter: give each manager its own subscriber
• share/eds: warm the EDS roots once before the parallel subtests
• re-enable the -race job in go-ci.yml (closes ci(unit tests): YOINK unit tests with race detector temporarily #3147)

Verified

With all three fixes applied, the full unit suite passes under -race — 41/41
packages, locally. Re-enabling may still surface rarer intermittent races on CI
hardware; those can be handled iteratively.

I'd like to drive this. Separately, I've found several latent production races by
inspection that the current tests don't exercise — I'll send those as follow-ups
with regression tests once -race is back to guard against regressions.

[neyy91]

@vgonkivs hello
Update: all three test-side fixes from the checklist are now merged into main:

• libs/utils: maxActive → atomic - test(libs/utils): fix data race on maxActive in TestSessions_Concurre… #5060
• shrex_getter: per-manager subscriber - test(shrex_getter): give each peer manager its own header subscriber #5074
• share/eds: warm EDS roots before parallel subtests - test(share/eds): warm EDS roots before parallel accessor subtests #5075

That clears the blockers I found locally. The only remaining step is flipping the
job back on. I'd like to open the final PR that uncomments the -race unit-test
job in .github/workflows/go-ci.yml (closing #3147).

One open question before I do - how would you prefer to handle any rarer
intermittent races that only show up on CI hardware and not locally? Two options:

1. Re-enable as required and fix any CI-only flake as it appears (strictest,
   but may block PRs until sorted).
2. Re-enable as non-blocking / informational first for a short bake-in, then
   promote it to required once it's proven stable on CI.

Any option works for me - just let me know which one aligns with the team's CI policy, and
I'll submit a PR.

[neyy91]

Opened #<5121> to flip the job back on - all three test-side blockers are
merged, and I verified the previously-racy packages pass under -race locally.
Left an open question in the PR on whether you'd want it required immediately or
non-blocking for a few runs first.