Incremental adjacency cache: share row objects across indexes; per-lookup cost != set-growth cost

Fixing an O(actors x relations) hot loop in a tick sim (relations_of hit SQLite ~1.7M times/run). An INVALIDATE-on-write cache did NOT help — writes interleave with reads within a tick, so it rebuilt constantly. The fix is an INCREMENTAL write-through cache with a key trick: keep three indexes (by a_id list, by (a,b) pair for O(1) _rel, by rel_id) that all hold the SAME dict object per row — so update_relation mutates one object and all indexes see it, no re-sync. link appends, delete invalidates (rare). Repoint the hottest helpers to the O(1) pair index. Result: realistic world 1000 ms/tick -> 8 ms/tick. BIG lesson though: this only fixes PER-LOOKUP cost. A pathological config was still slow because the relation SET was GROWING unboundedly under churn (stale edges accumulating faster than GC) — O(1) lookups over a set that grows to thousands is still slow. Distinguish per-operation cost from data-growth cost when profiling: if trimming ticks changes the story, it is growth, not per-op. Also profile CALL COUNTS and pin PYTHONHASHSEED, since set-iteration order changed how much churn/relations accumulated run-to-run.