maintain-packaging

# Maintain Release And Packaging Surfaces Use this skill when a change affects how NeMo Relay is built, packaged, named, or consumed outside the source tree. ## Audit Areas - Rust `Cargo.toml` package names and workspace metadata - Python packaging in `pyproject.toml` - Python worker plugin SDK packaging in `python/plugin/pyproject.toml` - Go module path in `go/nemo_relay/go.mod` - Node workspace metadata in root `package.json` and `package-lock.json` - Node package metadata in `crates/node/package.json` - FFI header and library naming - CI workflows, install commands, and example commands - `justfile` build, test, clean, version, and package recipes for plugin crates and packages - Release tags, release-note surfaces, and registry-facing version translation ## Checklist - [ ] Every new package or plugin has an explicit versioning model: either it participates in the unified NeMo Relay release or it has an intentionally independent source of truth - [ ] Package names, import paths, and module names are internally consistent - [ ] Generated artifacts still land where downstream consumers expect - [ ] Docs and examples use the current install/import/build commands - [ ] CI references the same package names as local workflows - [ ] Public packaging changes are reflected in release-facing docs - [ ] For a new unified-release surface, its manifest version, lockfile entry, and internal NeMo Relay version pins are covered by `set_project_version` in th...