Edge (vnext) CLI stamps its snapshot version into the Dockerfile runtime download URL — image builds 404

[initializ-mk]

Symptom

An agent generated by the vnext prerelease CLI fails at image build: the generated Dockerfile's runtime download URL points at a release tag that doesn't exist.

The CLI binary from the vnext release is stamped with its snapshot version (vnext-SNAPSHOT-<sha> shape), and BuildTemplateDataFromContext (forge-core/compiler/template_data.go:149-155) passes the CLI's own version through as the download tag almost verbatim — only ""/"dev" map to latest:

v := bc.ForgeCLIVersion
if v == "" || v == "dev" {
    v = "latest"
} else if v[0] != 'v' {
    v = "v" + v
}
d.ForgeVersion = v

Rendered into templates/Dockerfile.tmpl:76:

https://github.com/initializ/forge/releases/download/vnext-SNAPSHOT-<sha>/forge-Linux-${ARCH}.tar.gz   → 404

The release TAG is vnext; the snapshot version exists only inside the binary's stamp.

Field workaround (currently in a working CI pipeline)

- name: Pin runtime download to the vnext release tag
  run: sed -i -E 's|releases/download/[^/\"]+/forge-Linux|releases/download/vnext/forge-Linux|' .forge-output/Dockerfile

Every consumer of the edge channel needs this today.

Suggested fix

In the version normalization above, map snapshot-stamped versions to the tag that actually hosts them: edge.yaml (the only producer of snapshot-stamped release binaries) publishes them under vnext, so a version containing -SNAPSHOT- (or prefixed vnext) should resolve to vnext. Local dev builds already hit the dev → latest branch, so the mapping doesn't collide with them.

Worth a regression test at the template-data level: ForgeCLIVersion = \"vnext-SNAPSHOT-abc1234\" → d.ForgeVersion == \"vnext\".

Why it matters right now

The two runtime fixes in flight (#370 hyphenated MCP tool names, the ANTHROPIC_BASE_URL env gap) reach customers through the vnext channel + agent rebuilds — a channel whose CLI currently generates images that can't build without the sed patch.