Key compiled animation clip cache by identity, not asset name

[untoldengine]

Summary

• AnimationComponent.compiledClip(for:) cached compiled pose data keyed by AnimationClip.name, which comes from the asset file (e.g. the source Blender action name), not the lookup name passed to setEntityAnimations/changeAnimation.
• Two independently exported clips (e.g. idle and running) commonly share the same embedded name, so the second clip's compiled data collided with the first's cache entry — changeAnimation correctly swapped currentAnimation, but playback stayed on the previously cached clip.
• Fixes it by keying compiledClips on ObjectIdentifier(clip) instead of the name, so the cache is correct regardless of what name the source asset embeds. removeAnimationClip updated to match.

Test plan

• swift build
• swift test --filter AnimationCompiledSamplerTests (12/12 passing, including compiled-vs-legacy parity and the sampling performance baseline)

[miogds]

Identity keys are the right fix. Two things worth closing while you're in there, plus one nice-to-have.

1. Stale entries can outlive their clip. registerRuntimeAnimationClips (RegistrationSystem.swift, the assignments at ~827 and ~836) writes into animationClips directly and never evicts compiledClips when it replaces an existing entry (the same embedded name registered twice, or a reload). CompiledAnimationClip does not retain its source clip, so the replaced AnimationClip is freed while its cache entry stays keyed on the old ObjectIdentifier. Swift reuses freed addresses, so a clip allocated later can inherit that identity and be served the dead clip's compiled data: the same failure, now nondeterministic instead of by name. The cheapest complete fix is pruning on mutation:

var animationClips: [String: AnimationClip] = [:] {
    didSet {
        let live = Set(animationClips.values.map(ObjectIdentifier.init))
        compiledClips = compiledClips.filter { live.contains($0.key) }
    }
}

removeAnimationClip then needs no special handling. Alternatively, have CompiledAnimationClip hold a strong reference to its source clip, which turns the hazard into a bounded leak instead of wrong data.

2. No regression test. Tests/UntoldEngineTests/AnimationCompiledSamplerTests.swift already builds clips from RuntimeAnimationClip (makeWalkClip / makeIdleClip), so the test is small: give both clips the same name, compile both through one AnimationComponent.compiledClip(for:skeleton:), and assert the channel data differs (one translation key from each is enough). A second case covers (1): register and compile a clip, replace it under the same key, allocate a new clip, compile it, and expect fresh data.

Nice-to-have: the preferredName alias creates a second AnimationClip from the same runtime clip, so with identity keys it now compiles twice. Registering the same instance under both names keeps a single compiled copy.

For the record, the CoolZombie clips are unaffected (each exported action is named after its clip), so this only bites assets whose actions kept a default name.