Extract an IdentityIndex: one owner for keyMap + identity matching/canonicalization #28

Problem

Engine is trending toward a god object (~1,200 lines): document state, history, mutation ops, structural diff, the items() read model, and canonicalization plumbing. The identity layer in particular is a concept without an owner: the keyMap (Map<string, string> of stringly-typed patterns) lives as private engine state and gets threaded as a parameter into loose functions in src/paths.ts (canonicalizeSegs, plus the pattern helpers it depends on).

v1 had this right once before (7d2c949, "keyed-internal arrays for stable op targeting"): identity addressing as an explicit internal layer, translation at the boundary. The v2 simplification removed it; 0.13–0.15 rebuilt the behavior but as scattered machinery rather than a layer.

Proposed shape

An IdentityIndex (name negotiable) constructed from the schema, owning:

• the pattern→key map (today extractKeyMap output),
• key lookup for a location (keyFor(pattern)),
• canonicalization (canonicalize(doc, segments) — today canonicalizeSegs),
• resolution (resolve(doc, segs) — today resolveCanonical),
• the per-call key-override mechanics that diff(path, { key }) currently does by swapping the whole map.

Engine holds one instance and stops knowing about patterns entirely.

Why before ordered arrays

Ordered keyed arrays (move op emission, position anchors — discussed but deliberately deferred) will add more identity-layer logic. Better to give the layer a home first than to scatter a third feature across the same five seams.

Origin: self-review finding #5 on the identity-paths change set (0.13–0.15, branch claude/practical-shannon-jr19ie).