Morph target system creates one compute encoder per primitive per frame

## Summary
For each primitive that has morph targets, `applyMorphTargetsCompute` creates a new `MTLComputeCommandEncoder`, dispatches work, and ends encoding. A model with 10 morph-enabled primitives incurs 10 compute encoder create/teardown cycles per frame.

## Impact
- CPU overhead from encoder creation/destruction.
- GPU bubbles between tiny dispatches.
- When the active morph set is empty, the system still creates a blit encoder to copy base positions to output.

## Location
- Renderer loop: `Sources/VRMMetalKit/Renderer/VRMRenderer.swift:950–1135`
- Compute encoder creation: `Sources/VRMMetalKit/Animation/VRMMorphTargets.swift:357–387`
- Blit fallback: `Sources/VRMMetalKit/Animation/VRMMorphTargets.swift:321–330`

## Evidence
```swift
for (meshIndex, mesh) in model.meshes.enumerated() {
for (primitiveIndex, primitive) in mesh.primitives.enumerated() where !primitive.morphTargets.isEmpty {
// ... creates new compute encoder per primitive
morphTargetSystem.applyMorphsCompute(...)
}
}
```

## Suggested Fix
Batch all morph work into a **single compute encoder per frame**:
1. Collect all active morph primitives into a GPU buffer or argument buffer.
2. Dispatch one large compute pass that processes all primitives in parallel.
3. Skip the blit copy entirely when a primitive has no active morphs.

Read the renderer loop in Sources/VRMMetalKit/Renderer/VRMRenderer.swift:950–1135 and encoder paths in Sources/VRMMetalKit/Animation/VRMMorphTargets.swift:321–330 and 357–387. Trace how morph-enabled primitives and active morph sets are submitted, then verify that morph work is batched per frame and that inactive primitives avoid the blit fallback without changing output.

Written by the indexing model from the issue text.