chore(release): 0.7.0

[LeadcodeDev]

Bumps the workspace to 0.7.0. One file changes — [workspace.package] and the
three internal requirements below it — and the five crates inherit.

Why minor and not patch

The published binary no longer carries the studio subcommand. Someone who
typed rustmotion studio -f scenario.json now types rustmotion-studio -f scenario.json. The capability is intact — rustmotion-studio declares its own
binary of that name — but the command changed, so the version does too.

It was not a choice: rustmotion-studio depends on rustmotion, so the published
crate cannot depend on the studio even optionally without cargo rejecting a cycle.

What 0.7.0 contains

#217 — cargo install rustmotion works. It could not before. The README
documented it and the crate called itself "a CLI tool", but the published crate
carried only a [lib]; the binary lived in rustmotion-cli, which is
publish = false. Installing gave a library and no command.

#216 — docs.rs can build again. skia-bindings 0.82 has a broken docs.rs path
in its build script, which is why 0.6.1 published with no documentation. The
workspace moved to skia-safe 0.99, which meant migrating Path to PathBuf
across 22 files and, once the deprecations surfaced, migrating off the gradient
shader API entirely rather than silencing it. No #[allow(deprecated)] remains.

Both releases also removed a defect of the same family — code reading files that
sit outside its own crate, invisible until something builds a tarball. The theme
files in #216, the skills tree and CLAUDE.md in #217.

Verification

cargo fmt --all --check	clean
cargo clippy --workspace --all-targets -- -D warnings	clean
cargo test --workspace	1241 passed, 0 failed
cargo publish --workspace --dry-run	exit 0 — four crates packaged, verified, upload order core → html → components → rustmotion

And the claim this release exists to make, tested rather than asserted:

$ cargo install --path crates/rustmotion --root /tmp/rm_install --locked
   Installed package `rustmotion v0.7.0` (executable `rustmotion`)
$ /tmp/rm_install/bin/rustmotion --version
rustmotion 0.7.0
$ /tmp/rm_install/bin/rustmotion validate -f out/mestier/mestier.json
Valid scenario: 6 scene(s) in 1 view(s)

Releasing

Merge, then tag 0.7.0 on the merge commit — a tag-triggered workflow reads
its definition from the tag's own commit, which is what stranded 0.6.0.

rustmotion-core 0.6.0 remains on crates.io as a stray version from that failed
run. Yanking it is a separate decision and is deliberately not part of this PR.