Fail pinning updates when rendering fails and update all shared consumers #31

During a correctness pass with Astra we found the following issue:

Author's preface above. Issue details below written by Astra (AI assistant) on 2026-10-09.

The pinning update path has two consistency gaps:

1. update_pinning ignores the return code from render-pinning. [INFERENCE] If rendering fails and leaves the old file intact, the command can report that the pins did not change and that there is nothing to rebuild.
2. Updating a distro that follows shared pinning rewrites the shared input, but only renders and plans a rebuild for the requested distro. Other followers keep stale generated pins, mutex constraints and build numbers.

These are source-traced findings, not forced-failure runtime reproductions. All four current distros have explicit pinning versions, so the shared-consumer case is latent today. new-distro deliberately creates shared followers.

Code: tools/maintenance.py, tools/maintenance.py and tools/maintenance.py.

Suggested change

Stop immediately on renderer failure and avoid leaving a successful-looking partial update. When shared pins change, calculate and commit the update for all followers together, including their combined dependency requirements. Alternatively, make per-distro bot updates own their pinning instead of editing shared state.

Acceptance criteria

• A failed renderer returns a failed result and never reports a successful no-rebuild update.
• A failed update preserves or restores the previous consistent pinning state.
• With two shared followers, updating shared pins updates both generated configs and rebuild/mutex decisions, or the operation refuses with a clear explanation.
• A distro with its own pins remains unchanged by an unrelated shared update.
• Regression tests cover renderer failure and multiple followers.