Add Lottie animation support for scene compositions

[kiyeonjeon21]

Why

Lottie (bodymovin JSON) is the de-facto format for lightweight vector
animation — animated logos, UI hints, transition cards, decorative loops.
Huge free corpus on LottieFiles. Right now VibeFrame can generate AI
clips and hand-author HTML scenes, but there's no first-class path for
designer-authored vector motion.

Possible shapes (looking for input)

A. HTML-native. Drop <lottie-player> (lottie-web) directly into a
composition HTML. Hyperframes captures the frames as-is. Simplest — works
today if you author the HTML by hand. No CLI hook, no agent affordance.

B. Remotion component. Wrap @remotion/lottie inside a Remotion
composition that VibeFrame renders. Reuses the same Remotion path that
already powers vibe generate motion. Programmatic start/end frames,
speed, loop count, prop-driven.

C. Hybrid. New primitive vibe generate lottie <file.json> -o clip.mp4
(Remotion under the hood) + a vibe scene add lottie helper that mounts
the rendered clip into a scene like any other video. Each step a discrete
verb that produces a file the next step consumes.

I lean C because every other VibeFrame primitive follows the same
"discrete CLI verb → file → next step" shape and that's what makes the
agent flow predictable. But A is way cheaper if "good enough" is the
bar, and we'd be skipping a Remotion dep we don't need yet.

Open questions

• Bundle a small starter library of CC0 Lotties, or strictly BYO file?
• Trimming: --start-frame/--end-frame, or just --duration + --loop?
• Should vibe build auto-detect .json/.lottie files under assets/
  and surface them as scene candidates?
• Naming — vibe generate lottie vs. extending vibe generate motion
  with --from-lottie <file>?

Acceptance (rough)

End-to-end working path: .json file from LottieFiles → mounted in a scene
→ frame-accurate render via vibe render. One example under docs/.
Agent tool exposed if B or C wins.

Pushback welcome — I'd rather get the API shape right than ship fast.

[kiyeonjeon21]

Maintainer note: this issue is now partially implemented and the remaining scope should be narrowed.

Current main already has a first-class Lottie path in several places:

• timeline sources can use type: "lottie"
• the Hyperframes renderer vendors the dotlottie runtime and emits <dotlottie-wc> for Lottie clips
• vibe edit motion-overlay --asset <file.json|file.lottie> supports user-provided Lottie overlays
• the tool manifest / CLI reference expose the Lottie overlay options

That covers a good part of option C from the original issue, but not the whole acceptance criteria yet. The parts that still look open are:

• an end-to-end docs example using a real .json / .lottie file through render
• a clearer scene-project helper if we want vibe scene add lottie or vibe build auto-discovery under assets/
• deciding whether vibe generate lottie is still desired, or whether prompt-to-Lottie stays out of scope

I would not close this yet, but future work should avoid re-implementing the renderer path. The issue can now be treated as API/docs polish around the existing Lottie support.