feat(cli): ship the binary from the published crate

[LeadcodeDev]

cargo install rustmotion cannot work today. The README documents it at line 12,
and the crate describes itself as "a CLI tool", but the published crate carries
only a [lib] — the rustmotion binary is declared in rustmotion-cli, which is
publish = false. Anyone following the documented instruction installs a library
and gets no command.

No issue tracks this; it was found while looking for the binary to reproduce an
unrelated studio bug.

The binary moves into the published crate

crates/rustmotion-cli is gone and its 21 files moved under crates/rustmotion
via git mv, so history follows. Six subcommands — render, concat,
validate, schema, info, completions — keep their behaviour exactly.

The studio subcommand could not come along

Not a scoping choice. rustmotion-studio depends on rustmotion, so making
rustmotion depend on the studio — even optionally — is a cycle, and cargo
refuses before compiling:

cyclic package dependency: package `rustmotion` depends on itself.
  ... rustmotion-studio depends on rustmotion
  ... rustmotion depends on rustmotion-studio

Nothing is lost. rustmotion-studio already declares its own binary of that name,
so the studio is launched directly rather than through rustmotion studio.

A second defect, found by moving

Latent while the crate was unpublished, and the same class as the themes bug fixed
in #216: build.rs walked .claude/skills/rustmotion/ and skills.rs embedded
CLAUDE.md — both outside the package directory. cargo package archives only
what lives under the crate, so the tarball did not compile:

panicked at build.rs: expected .../target/.claude/skills/rustmotion/SKILL.md
to exist — is the workspace layout intact?

Left alone, this PR would have replaced "no binary" with "cannot publish at all".

Both now live inside the crate, with symlinks at their old paths so Claude
Code still finds them. One copy, deliberately: this repository already learned in
#165 what a duplicated skill list costs when it drifts — 17 files behind, no build
or test failing — and tests/skill_files_match_disk.rs, written for that
incident, still guards it.

Verification

cargo fmt --all --check	clean
cargo clippy --workspace --all-targets -- -D warnings	clean
cargo test --workspace	1241 passed, 0 failed, 10 ignored
cargo package -p rustmotion	exit 0, verification included — 112 files, 1.6 MiB, 58 skill files and CLAUDE.md in the tarball

--help proves nothing here, so the built binary was exercised: validate and
info on a real scenario, schema, still, render --frame, render --frames
with its audio slice, completions generate zsh, and rustmotion-studio --help
still works.

The one that mattered most, since build.rs now embeds a destination that differs
from the source path: running skills install in an empty directory writes 59
files to .claude/skills/rustmotion/, exactly where it wrote them before.

Left alone on purpose

docs/superpowers/plans/ still cites crates/rustmotion-cli. Those are June
planning records; rewriting them would falsify an account of what was done.