Keep memo key reads out of untracked callers (#122)

[ryanbliss]

Fixes #122. Stacked on #125.

When a keyed memo had to re-run its key, runKeyedMemo called replayDependencyComparisonAccesses without a guard. That happens on a memo's first read, and also after one of its key inputs changes. So even when the caller had paused tracking with Retree.untracked, the outer selector or effect inherited the key's reads. Validated hits went through replayTrappedMemo, which already checked isDependencyTrackingActive().

The check now lives in replayDependencyComparisonAccesses, so every replay honors it. runFrame resets the pause depth for nested frames, so a memo's own key frame still tracks its reads for gating.

Intended side effect: a keyed memo read inside another memo's body (which also pauses tracking) no longer replays its key into the enclosing frame on a cold run. That matches the warm path and runMemoBody's design.

Performance: the check stays the cheap isDependencyTrackingActive() exit outside any frame. Review measured warm memo hits in a 2M-read loop at the same speed as before this change.

Tests

• A new it.each in memo.spec.ts covers a cold memo under Retree.select and Retree.effect, and a stale memo (key input changed) under Retree.select. All three fail without the fix.
• npm run test (with NODE_PATH unset, see Keep the query baseline from owning cached results (#117) #124), core typecheck and npm run doctor all pass.
• An Opus subagent reviewed this. I took its performance, wording and coverage findings.