fix(subnets): count WeightsSet setters by uid, not by an absent hotkey

[JSONbored]

The bug

/subnets/{netuid}/event-summary credited WeightsSet — usually the highest-volume kind on the subnet — with 0 distinct participants beside a five-figure event count. Measured live on netuid 64 at the route's default 30d window:

{"event_kind":"WeightsSet","event_count":9830,"hotkey_count":0,"coldkey_count":0}

The real distinct-setter count is 15 (17 at 90d). Every other kind on the card was already correct.

Cause

The per-kind actor count grouped on hotkey alone. The WeightsSet chain event emits [netuid, uid] and carries no hotkey — the column is NULL on all 50,890,747 rows in the export — so hotkey IS NOT NULL dropped every row, the kind never appeared in that read, and the merge filled the gap with 0.

The retired Postgres route counted a composite hotkey-or-uid identity for exactly this reason, and said so: "the distinct-actor count uses the same hotkey-or-(netuid,uid) identity as the weight-setters routes (WeightsSet ingestion can omit hotkey)". So this was a fidelity regression against prior behaviour, not a gap in the source data.

netuid is fixed by the WHERE here, so a bare uid is unambiguous — the retired query spelled the pair only because it was not subnet-scoped. A row carrying neither key collapses to a NULL actor that the outer filter drops, reproducing COUNT(DISTINCT)'s own NULL handling, which is what the previous per-column filter existed to do.

coldkey_count deliberately keeps the plain distinct. A WeightsSet has no delegating account, so there is nothing to fall back to and its zero there is genuine.

Why this one mattered

Zero was published as a measured value on the busiest row of the card — the same confident-zero failure this lane has been removing (#9285, #9289). The reader's own header warns against publishing "9,832 WeightsSet events from 0 hotkeys"; it guarded that against a failed query, but not against the identity itself producing it.

Verification

Against the live engine, using the SQL the reader actually emits — not a hand-written approximation and not only its fake engine:

Window	WeightsSet actors	Other kinds
30d	0 → 15	byte-identical to production
90d	0 → 17	byte-identical to production

Every other kind (StakeAdded 65, StakeRemoved 82, AutoStakeAdded 6, StakeMoved 30, StakeTransferred 16, StakeSwapped 18, SetChildrenScheduled 19, NeuronRegistered 25, AxonServed 1) matches what the route already serves, so the change is strictly additive — it fixes one kind and perturbs nothing else.

Note on the tests

The tests pinning the old behaviour asserted the implementation rather than the route's contract — one literally read assert.equal(byKind.WeightsSet.hotkey_count, 0, "WeightsSet carries no hotkey, so 0"). They passed at 100% coverage while the card published a wrong number. Corrected here to assert the contract, with a dedicated test for the fallback; confirmed they bite by restoring the hotkey-only grouping (6 tests fail).

Checks

• typecheck, lint, prettier: clean.
• 2,840 tests green across the reader, REST, MCP, GraphQL and account-events suites.
• contract-drift, no-hand-written-mjs, module-state-resets, private-boundary: pass. No contract change.
• Patch coverage 2/2 = 100%, branch-counted, by diff intersection.

Closes #9308
Refs #9146

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	metagraphed-data-api	a4bc8de	Aug 03 2026, 08:54 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	metagraphed-registry-sync-api	a4bc8de	Aug 03 2026, 08:54 PM