Finish the publish chain: rc-car-actuator to PyPI, then an opencastor release

## Why (bench evidence, 2026-08-14)
rc-car-actuator is NOT on PyPI, so a fresh `pip install opencastor` resolves the gateway but degrades the actuator to noop (castor up says so honestly, but the ten-minute path should not need a second pip install). Dists are BUILT and twine-checked (rc_car_actuator-0.1.0 wheel+sdist in the repo's dist/). Upload is blocked ONLY on the operator's PyPI token — no credential reachable from the Pi (no .pypirc, keyring empty, not in the service-account vault).

## What
1. Operator uploads: `TWINE_USERNAME=__token__ TWINE_PASSWORD= ~/venvs/pypi/bin/twine upload ~/projects/RobotRegistryFoundation/rc-car-actuator/dist/*`
2. Verify cold install resolves the `rc-car` entry point (castor up flips noop → rc-car on rerun, tokens preserved — behavior already pinned by test)
3. Cut an opencastor release carrying the `rc-car-actuator>=0.1.0` dependency (commit 1233832) via the local-twine flow
4. Consider: also publish today's actuator work (battery gauge, shutdown-neutral, registry) as 0.1.0 content — it is all committed

## Acceptance
- `pip install opencastor` in a clean venv → `castor up --no-start` reports `actuator: rc-car (simulated wheels)`

## Pointers
- Publish order matters: rc-car-actuator FIRST (opencastor's resolver will 404 otherwise)

Start with rc-car-actuator/dist/* and the stated twine upload command, then inspect commit 1233832 for the opencastor dependency and local-twine release flow. Verify the clean-venv acceptance command and confirm that the rc-car entry point resolves and castor up --no-start reports the simulated-wheels actuator.

Written by the indexing model from the issue text.