perf(#5954): drop the per-entity centrality pre-seed and the eager names map

[cajasmota]

What

Removes two allocations from RunAlgorithmsWithOptions: a per-entity zero pre-seed of the betw and pr maps (~433k entries each on the reference corpus), and an eager names map[string]string held live for the whole pass.

Measured — and much smaller than estimated

~17 MB, not the ~135 MB this was scoped at. The estimate was wrong for two reasons, both found by measuring rather than reasoning:

• pr's pre-seed saved zero bytes. network.PageRankSparse returns a score for every node and BuildGraph inserts a node per entity, so the map is fully populated one loop later regardless. Removing the pre-seed eliminates ~433k redundant map writes — a CPU win, not a memory one.
• Betweenness is not "mostly zeros". On a realistically-connected graph it is non-zero for 91% of nodes (394,494 / 433,333, independently reproduced at 60k entities → 91.05%). Sparsifying saves ~9% of one map.

The names map was the entire prize: 21.5 MB → 6.6 MB via []string indexed by node id.

End-to-end at 433,333 entities / 2.67M rels: live heap holding the result 1004 → 1003 MB, len(Centrality) 433,333 → 394,494.

What the pre-seeded keys were load-bearing for — all three preserved

1. IdentifyGodNodes took k = len(m)/20, and zero-scored entities filled the cut in id order when positives ran out. identifyGodNodesFrom now takes the universe from the node index: positives ranked first, then the zero tail by id. k is computed over the same universe (int(idx.next) == distinct entity count), so the cut size is unchanged.
2. Entity.Centrality is *float64 with omitempty — nil omits the key, pointer-to-zero emits "centrality":0. Both attachment loops now gate on PageRank membership (still dense, exactly the entities in the pass) and read centrality with the zero default.
3. groupalgo.BuildOverlay already zero-defaulted and iterates PageRank; EntityOverlay.Centrality is a non-pointer float64 with no omitempty. Overlay bytes unchanged, no OverlayAlgoVersion bump.

Verified byte-identical

Differential tests run at 536876b3a vs this commit, on fixtures built specifically for the removed pre-seed's cases — a 30-node chain (non-zero interiors), a 20-pair perfect matching (all-zero betweenness, connected), and 50 fully isolated entities:

surface	base	new	diff
graph.json entities	len(Centrality)=120, 12 god nodes	len(Centrality)=28, 12 god nodes	byte-identical
group overlay JSON	—	—	byte-identical
god-node cut filled entirely from the zero tail (400 entities, k=20, 10 positives)	20 god nodes	20 god nodes	byte-identical

Every "centrality":0 survives, including for entities absent from any relationship.

The god-node parity oracle (legacyIdentifyGodNodes) is a verbatim copy of the pre-change implementation, diffed line-by-line; it shares no code with the new path.

Test gap found in review and closed

Reverting both attachment sites to if c, ok := res.Centrality[e.ID]; ok originally passed the entire suite — precisely the edit that would silently drop "centrality":0 for ~9% of entities. The parity test mirrored the attachment loop rather than invoking it. Two new tests now call the real loops (runPass4Algorithms, attachAlgorithmResults) on a fixture containing zero-betweenness and isolated entities, and assert the serialised form contains "centrality":0 — pinning the omitempty behaviour, not just the pointer. Mutation confirmed dead at both sites.

Downgrade note (corrected)

The dashboard's graph-algo.json sidecar now serialises a sparse Centrality map. loadPersistedAlgoResults keys on the graph.fb mtime only — no binary or schema version — so this is not version-invalidated. An older binary reading a new sidecar without re-indexing leaves Centrality nil for zero-betweenness entities and omits betweenness instead of emitting 0. Cosmetic; pagerank/community/god-node/articulation unaffected; re-indexing rewrites it. The forward direction is exact.

Also

Exported IdentifyGodNodes is deleted. It ranked each map over its own key set, which was the entity universe only while the pre-seed existed — post-change an entry point taking just the two maps cannot compute the cut correctly, so leaving it exported would invite a subtly wrong call. Zero callers, zero direct tests.

Independently adversarially reviewed.

Refs #5954