Shrink what the generator reads first

[LeadcodeDev]

Part of #326. Phase A is batch 1 and touches no engine code. Phase B is batch 4 and depends on #327, #328 and #329.

Across the eleven files in examples/, five component types carry 82% of roughly 690 instances: text 266, div 100, card 98, flex 61, shape 44. Twenty-seven types appear exactly once in the whole repository. dark-premium.json uses four types, ferriskey-presentation.json seven, 1600-style.json nine. mega-showcase.json uses fifty-four, and its job is to demonstrate the catalogue. The only file that uses the catalogue is the file that exists to show it.

Presenting sixty components and fifty-five rule files to a generator fills its head with a catalogue and produces a slide deck. The rebuild that measured this chantier used six types and came out at 42 nodes against 233 for ferriskey-launch-60s.json, so the catalogue is not what forces that shape, but it is what the generator reads first.

The three classes are not treated alike. Roughly seventeen components are algorithms that cannot be composed from drawing primitives: chart and its twelve types, codeblock with syntect highlighting and diff mode, terminal, qr_code, dot_map and its land bitmap, treemap, heatmap, table, lottie, video, gif, caption, the two FFT-driven audio components, mockup, image. Those stay. Roughly fourteen are primitives and are deepened by #332. The remaining twenty-seven are frozen compositions of card, text, shape and an animation.

Those twenty-seven do not become a shipped library either. A library is still a default that anchors, and a generator will fill stat rather than design one. A component defined inside a scenario beats a global one, because art direction is per video, and components with for-each already provides exactly that. What ships instead is worked example scenarios showing how to compose. An example teaches composition; a library teaches filling in blanks.

This writes off real recent work. success_check, number_wheel and pointer are careful, documented and mapped to the Hyperframes vocabulary, and they are in the set.

Owned files

• .claude/skills/rustmotion/SKILL.md and .claude/skills/rustmotion/rules/**
• examples/** (the new composition examples)
• crates/rustmotion-components/src/lib.rs (phase B only — deprecation attributes)

Do NOT write: any component implementation file, anything under crates/rustmotion-core/.

Deliverables

Phase A, no engine change and available immediately.

1. The skill stops presenting the twenty-seven. Around half the fifty-five rule files exist to document their quirks (counter-standalone.md, grid-card-height.md, badge-video-sizing.md, stat-cards.md, notification-stacking.md) and go with them.
2. Three or four worked example scenarios built from primitives and components, replacing the catalogue tour as the thing a generator reads first.
3. A decision recorded in the skill: nothing is added to the twenty-seven from now on.

Phase B, after the expression work lands.

4. The enum variants carry a deprecation attribute and a warning naming the composition that replaces them. They keep working.
5. Removal is a major version with rustmotion migrate (The timing gate and a migration command #335), never a silent break: existing scenarios, rustmotion-html and the studio all reference them.

Acceptance

• A generated scenario for a new subject uses fewer than ten component types without being told to
• Every existing example still validates and renders identically after phase A
• Phase B emits a deprecation warning and changes no rendered pixel

[LeadcodeDev]

Delivered on main at 187cf7c (squash of #340). Verified present on main, not taken on the PR's word.