Decouple node-image builds from the provider version + harden the qcow2 upload

Two related release-pipeline annoyances surfaced cutting v0.2.0 → v0.2.1:

1. Every release rebuilds the node images (~25-30 min each), even metadata-only patches

build-node-image publishes to capvco-images/<TAG>/…qcow2, keyed on the provider tag. So a patch that changes nothing about the images (e.g. v0.2.0→v0.2.1, a metadata/docs fix) still rebuilds both multi-GB images from scratch. Pure waste, and it widens the flake window (see #2 (closed)).

Proposal: publish node images to a version-keyed stable path (e.g. capvco-images/<os-target>-<k8s-version>/…qcow2) independent of the provider tag. build-node-image skips the build+upload when that image already exists; the release job references the stable path for its downloads/images/… asset links. Then a metadata/docs-only patch release publishes in ~2 min instead of ~30.

2. The qcow2 upload has no retry — a transient blip blocks the whole release

v0.2.0's build-node-image [v1.30.14] failed to post the artifact (the curl --upload-file to the package registry blipped), which — because node images are a required all-or-nothing gate — skipped release/pages and forced a full ~20-min rebuild on retry.

Proposal: add --retry 3 --retry-all-errors (and a short --retry-delay) to the qcow2 upload in build-node-image, and to the for f in out/* uploads in release-manifests, so a transient network error self-heals instead of dead-ending a release.

Benefit

Patch releases become cheap and fast; upload flakes stop costing a rebuild or a manual retry. Complements the pre-publish validation just added (which gates correctness; this gates cost/reliability).