perf(#5954): stop re-inflating compacted entity properties into a map in the link pass

[cajasmota]

What

entityNode.Properties in the link pass carried map[string]string, rebuilt from the already-compacted types.Props. It now carries types.Props directly.

Why

#5976 compacted RelationshipRecord.Properties from a map to a []propKV-backed types.Props, banking ~436 MB. The link pass then re-inflated it on load: one map header plus buckets per entity, across ~427k entities. This is self-inflicted waste rather than new engineering — it gives back part of a win we had already paid for.

Measured, not estimated

fixture	Props	map	saving
realistic distribution (25%×0, 50%×2, 15%×5, 10%×12 props, long keys)	94.4 B/entity	284.8 B/entity	~81 MB @ 427k
post-stamp steady state (4 extra Sets)	297.6 B/entity	475.6 B/entity	~76 MB @ 427k

BenchmarkEntityNodeProjection: 336 B/op, 2 allocs → 64 B/op, 1 alloc.

An earlier revision of this PR claimed ~119 MB. That came from a fixture with a uniform 2 properties per entity — near the map's worst case and the slice's best — and overstated the win by about a third. The uniform fixture is retained, but as the regression detector (a tight ceiling is exactly what you want there), not as the corpus estimate.

The committed tests measure allocation via TotalAlloc, not RSS. No committed test pins resident heap.

Translation

entityNode.Properties is populated by a new graph.Entity.PropsClone() — one exact-sized slice copy, no map. All read sites use Get/Lookup; all write sites use Set. Zero .Snapshot()/PropsFromMap bounces were added in non-test code.

Converted: openapi_pass, http_pass, constant_propagation, effect_propagation (signature changed map[string]string → *types.Props), sameas_pass, complexity_pass, dataflow_pass, def_use_pass, pure_function_pass, reachability, taint_flow, module_cycle_pass.

Link.Properties deliberately stays a map: it is built fresh by the matchers, never re-inflated from a compacted form, and there are thousands of links rather than hundreds of thousands of entities.

Semantic equivalence

Independently verified by review, since map and slice diverge in four ways that matter:

• nil vs empty — types.Props{} is non-nil, and PropsClone/PropsSnapshot both return nil for an empty set, so every == nil guard translates exactly.
• duplicate keys — impossible: Set binary-searches, then overwrites in place or inserts at the sorted position.
• iteration order — no exposure; nothing ranges over Properties, every read is keyed.
• aliasing — all 30 range …Entities sites that mutate use &g.Entities[ei]. Inserting through a value copy would be visible with a map and lost with a slice; no such site exists.

One dependency this change newly extends to the link pass: Props.Get binary-searches, so an unsorted backing slice silently returns "". Verified the invariant holds at both producers — fbwriter/writer.go:284-288 sorts before emission, load.go:541-556 relies on exactly that, and the JSON path sorts via propsFromMap. Entity.Prop() already binary-searched, so the invariant was load-bearing before; the blast radius is wider now.

Byte-identical output

9 golden files in testdata/linkout_5954/, generated from the pre-change map-backed implementation. The reviewer did not take that on trust: they built a detached worktree at the base commit, copied in only the diff test, regenerated, and diff -r'd against the committed goldens — identical. That also proves pre-change output was already deterministic, so there was no map-iteration-order leak for this change to alter.

Coverage is narrower than "9 goldens" suggests, and this is recorded rather than implied: only import, http, reachability, label and module_cycles emit anything; ten passes report links_added=0. The gate covers ~3 of the 14 converted passes. Six Set calls at four locations (def_use_pass.go:178-179, module_cycle_pass.go:145, pure_function_pass.go:91, dataflow_pass.go:552-553) are untested by anything in the package — all straight m[k]=v → p.Set(k,v) with no branching, and equally untested before.

Gate strength

TestEntityNodeProjection_MapReintroductionWouldFail bounds the ceiling against the cheapest re-inflation shape (PropsFromMap(PropsSnapshot()), 168 B/entity), not a bare map (336). Review found that a ceiling asserted only against 336 would admit a 200-byte limit that lets the 168-byte bounce through; that hole is now closed.

TestLinkPass_NoPropertyMapBounceInProductionCode is documented as load-bearing — it is the only test catching a re-inflation added anywhere other than newEntityNode — with its limits stated: a textual match on .Snapshot()/.PropsSnapshot() in non-test files of this package. A shadow map built via Range, or anything under cmd/, slips past.

Mutation results

Killed: map bounce in newEntityNode (both the byte gate and the static guard); ceiling loosened to 400; .Snapshot() added inside reachability.go; duplicate-key Set.

Recorded honestly: the duplicate-key kill is shape-dependent. Appending at the end breaks sort order and fails ~11 tests here. Inserting a duplicate at the correct sorted position is caught by nothing in internal/links — both golden tests pass — and only internal/types.TestPropsMatchesMapOracle fails. So this package's sensitivity comes from key order being observable in serialised output, not from key semantics being asserted anywhere.

Follow-up found by review

types.EntityRecord.Properties is still map[string]string, so cmd/grafel/index.go:1197 does Properties: pe.PropsSnapshot() on a per-entity loop — the same re-inflation, on the write path, outside this package's static guard. That is the next propKV slice, tracked separately.

Independently adversarially reviewed.

Refs #5954