build(sdk): pin imogen-sdk as a git submodule (#7)

[ergofobe]

Closes#7

Implements option 1 from the issue — the same way imogen-ios and imogen-android already
pin the SDK. Options 2 and 3 were considered and set aside: nothing is published yet
(ergofobe/imogen-sdk#3 is open), and a pinned rev would give up the edit-in-place
workflow the path dependency exists to support.

Summary

• imogen-sdk is vendored as a submodule at imogen-sdk/, so every commit here names the
  SDK commit it was built and tested against. Cargo.toml becomes path = "imogen-sdk/rust"
  and the load-bearing sibling-directory layout goes away — a plain clone or a git worktree
  now resolves the dependency wherever it lives.
• CI and release check it out with submodules: recursive, dropping the second
  actions/checkout and the mv ... ../imogen-sdk that only existed because
  actions/checkout refuses to write above the workspace root. release.yml's sdk_ref
  input is gone: a tag now names its own SDK commit instead of defaulting to whatever main
  was that day. Dispatching a release build against a different SDK is still possible — move
  the pointer on a branch and dispatch; the publish job is tag-gated, so nothing ships.
• CI now runs --locked. The lockfile is a second record of the same pin and CI used to
  regenerate it silently, so a bump that forgot to commit Cargo.lock went green and failed
  later at the release build — the only step that passed --locked. Main had already drifted
  this way: its lockfile said imogen-sdk 0.1.0 against an SDK at 0.2.0, so re-running the
  v0.2.0 release today would have failed. Refreshed here.

Test plan

• cargo test --locked — 103 passed, 2 ignored
• cargo fmt --check, cargo clippy --all-targets --locked -- -D warnings
• cargo build --release --locked
• cargo metadata resolves imogen-sdk to imogen-cli/imogen-sdk/rust, not to any
  sibling checkout — confirmed with a sibling imogen-sdk worktree present, so the
  submodule genuinely wins
• Submodule pointer 9e6a17a is origin/main of imogen-sdk and its v0.2.0 tag
• CI green on both ubuntu-latest and macos-latest

Notes

• The README quick-start (cargo install --path .) still assumes you already have a
  populated checkout; the Building section below it carries the --recurse-submodules
  instruction. Left as-is rather than putting a clone command in the opening hook.
• imogen-server has the same problem (SDK is resolved from an unpinned sibling checkout, so no commit records which SDK it was built against imogen-server#16) and is deliberately not
  touched here — separate repo, separate PR — but it should land on this same answer.
• The workspace's own worktree recipe for imogen-cli (add a sibling imogen-sdk worktree)
  is superseded by git submodule update --init --recursive; that file lives outside this
  repository.

🤖 Generated with Claude Code