Versioned releases: publish to the prefix.dev mote channel, replace rsync deploys

[MJohnson459]

Versioned releases: the first-party packages are now published as versioned conda packages to the prefix.dev mote channel, replacing rsync as the deployment mechanism. pixi run sync stays the dev loop. Branch release/versioned-packages, commit 6fa5217. Nothing has been pushed and nothing has been published.

WHAT CHANGED

Build. Every released package gets a small pixi.toml next to its package.xml pinning pixi-build-ros 0.5.0.* and the distro. They deliberately carry no version — package.xml is the single source of truth, and release/version.py (show/check/set) propagates one repo-wide semver from [workspace] version into every package.xml and setup.py. Set to 0.1.0.

Ten packages ship: the eight first-party ones, plus sllidar_ros2 and kinematic_icp. The submodules are not optional — a robot installing from the channel has no source tree to build them from, so without them it has no lidar driver and no odometry. They build from out-of-tree manifests under release/third_party/, because a pixi.toml inside a submodule would be an untracked file in someone else's repo. mote_simulation is excluded by policy (workstation-only, already excluded from sync); it builds fine if that changes.

Release chain. pixi run release = test -> regenerate deploy manifest -> build all ten into dist/channel (a local indexed channel) -> release-verify, which renders the robot deploy manifest against that channel and resolves it. Publishing is a separate human step (release-publish, typed confirmation); CI (.github/workflows/release.yml) builds and verifies both architectures on a v* tag but never uploads.

Robot updates. release/deploy/mote-update (plain bash, no Mote env needed) keeps versions in slots under ~/mote-deploy/ with an atomically flipped current symlink: stage / cutover / rollback / prune. Cutover is stop-then-start — the Pi has neither the CPU for two ROS stacks nor a second set of serial ports — health-gated, and rolls itself back if the units do not return. The deploy manifest's dependencies are generated from the workspace pixi.toml (a robot resolving a different set than the release was tested against is not running the release); its tasks are hand-written and curated, with names matching the workspace so runbooks and systemd units work on either.

Supporting fixes this exposed. mote_bringup now ships udev/, systemd/, networkmanager/ and tailscale/ into share/ — without that, pixi run setup was a checkout-only command and a released robot could never install its udev rules or systemd units. systemd/install.sh honours a MOTE_REPO override and resolves a new @DDS_CONFIG@ placeholder for either layout, with units pointed at the current symlink so a cutover redirects them without reinstalling.

WHY release-verify EXISTS

It caught ros-jazzy-mote-fleet declaring a dependency on ros-jazzy-python3-paho-mqtt — a package that does not exist, invented by the backend's fallback naming for a rosdep key RoboStack has no entry for. All ten packages built cleanly; the release was uninstallable. Fixed with extra-package-mappings, as scservo_linux -> scservo-linux already was for mote_hardware.

Two backend traps found and worked around, both documented in docs/releasing.md: release builds are always --clean, because the incremental hash covers package.xml and sources but not [package.build.config], so editing a dependency mapping silently reuses the cached recipe; and the backend is pinned to 0.5.0.* because pixi 0.70.2 provides build API v4 while the 0.6.x backends need v5.

HOW IT WAS VERIFIED

• All 410 existing tests pass (pixi run test), unaffected by the package.xml and setup.py changes.
• 32 new tests (pixi run test-release, own ROS-free env): no first-party package missing from the release set, backends pinned, no manifest duplicating the version, committed deploy manifest not stale, every task the systemd units invoke present in a deploy.
• A full stage -> cutover -> rollback -> prune cycle runs against a stub pixi and asserts ~/.mote comes out byte-identical — the runtime-state guarantee, tested rather than asserted in prose.
• pixi run release completes end to end on linux-64 (exit 0). All ten packages resolve from the freshly built channel; evidence committed at release/evidence/dry-run-linux-64.json.
• Package contents spot-checked: mote_hardware carries the plugin and all five tools with scservo-linux as a runtime dep; mote_bringup carries the udev/systemd/networkmanager/tailscale assets.
• pixi run lint clean.

NOT DONE, DELIBERATELY

Nothing published, no linux-aarch64 build produced (CI does it; that workflow has not run), and no on-robot rehearsal — the update flow is verified only against a stub pixi, not real systemd and hardware. Those are task 262, which needs Michael and a Pi. Task 263 proposes condafying py-trees and feetech-servo-sdk, the last two dependencies a released robot still resolves from PyPI.

Per the repo's git rule the branch is committed locally only — not pushed, and no PR opened.