Animation identity keys ship 8 B/row even when animation is disabled

[Alek99]

From a full data-transport audit at b0f8780.

Today: _transition_entry (python/xy/_payload.py:293-320) ships keys: {lo, hi} as two u32 columns whenever the user supplied key= — on every build including first paint — independent of whether the effective animation spec will ever animate (python/xy/components.py:3700-3731 requires keys for match=\"key\" but never strips them when animation is disabled). Bounded correctly by MAX_ANIMATION_MATCH_ROWS (200k) with recorded fallbacks, so worst case is 1.6 MB/payload.

Also on the same path:

• Key digesting is a per-row Python loop with hashlib.blake2s per row (components.py:3629-3651) — O(N) Python-object work at chart build, uncapped.
• Shipping does 3 copies for 8N bytes: keys[sel] gather then two ship_u32(values[:, i]) strided-column ascontiguousarray copies (_payload.py:309-317); the (N,2) array is contiguous, so values.reshape(-1) interleaved is zero-extra-copy in one buffer (client de-interleaves). And np.array(..., copy=True) at _payload.py:664 double-copies a fancy-index result that is already fresh.

Proposed fix: skip ship_u32 when animation is disabled or match != \"key\"; vectorize or native-kernel the key digest; interleave the u32 pair.