Signals mini

Implement signal() and effect() with automatic dependency tracking via a global 'currently-executing' variable. A signal holds a value and a subscriber set; effect(fn) sets the global to itself, runs fn, and any signal read inside fn checks the global and adds the effect to its subscribers — no explicit `effect.subscribe(signal)` list. Writing a signal (`signal.value = x`) re-runs exactly its dependent effects. Dependencies are dynamic: before each re-run the effect's previous subscriber set is cleared so a signal conditionally read in one branch (e.g. `if (flag.value) a.value else b.value`) stops triggering the effect when that branch is no longer taken — without clearing, stale subscriptions cause unnecessary re-runs and prevent GC while signals are alive. Prove it: an effect that reads signal A in the true branch and B in the false branch unsubscribes from the untaken branch when the condition flips, and a test where a signal stops being read stops triggering the effect.

Add computed(): lazy, cached, transitively tracked, and never re-evaluated unless a source actually changed. A computed holds a thunk `() => value`, a dirty flag, and its own subscriber set; it only evaluates on read (lazy) and returns the cached value if no source dirtied it since the last read. On evaluation it also participates in dependency tracking — so a computed read inside an effect transitively subscribes the effect to the computed's source signals, not just to the computed node itself. The chain is: source write → mark computed dirty → schedule effect → on flush, computed re-evaluates lazily (once) before the effect reads it. Prove it: a computed whose source hasn't changed returns the cached value with zero recomputations (count the thunk calls); a computed read inside an effect causes the effect to re-run when the source changes but not when an unrelated signal changes; and changing the source, reading the computed twice, and asserting the thunk ran exactly once.

Implement batching so multiple signal writes inside `batch(() => {...})` trigger each effect exactly once, after all writes, with no stale intermediate reads (glitches). The glitch: in a naive push graph, writing A immediately propagates to B and C, which immediately run their subscribers. If D depends on both B and C (diamond A→B, A→C, B&C→D), D runs when B updates (reading a stale C) and again when C updates — two evaluations, one with an inconsistent intermediate state. The fix is to defer flushing: mark dirty nodes, sort the reactive graph topologically, and flush in topological order so a computed is never evaluated while any of its sources are still dirty. Prove it with the diamond test: A→B, A→C, B&C→D updating D once with no stale read when A changes inside a batch, plus a count that D's effect ran exactly once for two writes inside batch. Explain why naive BFS/push without topological ordering produces glitches.

Add untrack() to read a signal without subscribing and onCleanup() so effects can release resources before re-running. untrack(() => signal.value) evaluates the function with the currently-executing global temporarily nulled so the read is invisible to dependency tracking — essential when an effect needs to read a value without becoming reactive to it (e.g. reading a logger signal or a previous-value cache). onCleanup(fn) registers a callback that runs before the effect's next re-run (and on disposal), so subscriptions, timers, or abort controllers created in the previous run are torn down before the next — without it, each re-run would leak. Prove both: untrack reading signal B inside an effect subscribed to A does not cause B's writes to re-run the effect; an effect that creates a timer and registers onCleanup(() => clearTimeout) cleans up exactly once per re-run with no leaked timers.

Prove the library scales and make the reactive graph observable. Benchmark: create 10k signals with a fan-out computed graph and measure batch cost — the topological sort and flush should be O(nodes + edges), not O(nodes × writes), so batching 100 writes still triggers each effect once and the cost is proportional to graph size, not write count. Emit lightweight metrics for the library itself: effect run count, computed eval count, batch flush count and duration. Then work an incident: create a 1000-node chain and kill batching (write without batch) to watch the same chain trigger 1000 cascading updates vs 1 batched flush — the performance cliff is the proof that batching is load-bearing. Document the complexity: per-write marking is O(subscribers), flush is O(sorted dirty nodes), and why virtualized rendering of the graph (not the library) would be a separate concern.