fix: global substitution in resolve_stable_release_with_asset

Used \${var/pattern/repl} (first match only) instead of \${var//pattern/repl}
(global). The buildx asset template contains {version} twice
(v{version}/buildx-v{version}...), so the second occurrence stayed literal,
breaking every candidate URL and exhausting the whole release list before
failing. Verified all three call sites (buildx, compose, compose-switch)
resolve correctly now.

fix(docker-in-docker): resolve buildx/compose versions via verified R…

…eleases API

Upstream resolves "latest" for buildx, docker-compose, and compose-switch via
git ls-remote --tags, then optimistically downloads an asset named after that
tag. This breaks whenever the repo pushes a tag (or CI snapshot/RC tag) before
publishing a matching release asset under the expected filename — which is
exactly what happened with docker/buildx v0.35.0 / v0.35.0-rc1/-rc2 (assets
named by commit hash instead of version), 404ing the whole feature install.

Replace this with resolve_stable_release_with_asset(): walks the GitHub
Releases API, skips prereleases/drafts, and verifies each candidate's asset
actually exists via HEAD request before committing to it, falling back
through older stable releases as needed.

Pruned to docker-in-docker only; dropped unrelated CI workflows.