Mutex: honour mutex_package.build_number; run_constraints optional

[Tobias-Fischer]

Publishing a new build of the mutex at the same version (mutex_package.build_number) didn't work. Two places used the distribution's build_number for the mutex instead of its own:

1. Skip-existing check (main.py): a published mutex counted as already built when its build number matched the distribution's build_number. So no recipe was generated (Skipping ros2-distro-mutex).
2. write_recipe (template.py): it overwrote every output's build number with the distribution's. The mutex recipe then had string: lyrical_28 but number: 27.

Fix:

• A new expected_build_number() gives the mutex its own build number and leaves other packages unchanged (the distribution's, or pkg_additional_info.yaml's). The skip check now uses it.
• write_recipe starts from the output's own build number before applying pkg_additional_info.yaml.

For a whole distribution (RoboStack lyrical, linux-64), the only recipe that changes is the mutex's: number: 27 → 28.

Tests: vinca/test_mutex_build_number.py covers the expected build numbers and the written mutex recipe. Without the template.py change, the recipe test fails. The full suite passes.

Also: run_constraints is optional. A mutex only has to keep one distribution per environment, so mutex_package no longer requires the key, and the recipe only lists run_constraints when there are any. RoboStack drops all mutex constraints: they applied to every user environment and made solvers fall back to old builds; wrong dependencies are fixed in the packages themselves.

Needed for RoboStack to publish the mutex again without run_constraints, at the same version, so that no other package needs a rebuild.

🤖 Generated with Claude Code