fix(release): run own-repo finalize from the source-built cascade binary

[joshua-temple]

The break

Cascade's own-repo generated `orchestrate.yaml` finalize job installed cascade via a pinned `setup-cli@... # v0.8.0`. Its `Manage Release` step now runs `cascade manage-release ... --tag-only`, but the v0.8.0 binary predates `--tag-only`, so every rc cut failed at finalize with `Error: unknown flag: --tag-only`. No published cascade carries `--tag-only` (it is unreleased), so bumping the pin cannot fix it.

The fix

Own-repo finalize now runs the binary built from the exact commit under release instead of a stale pin. The finalize job already depends on the `build-cli` callback, which compiles cascade from source. That callback now uploads its binary as a `cascade-cli` artifact (via the pinned `actions/upload-artifact`), and own-repo finalize downloads it onto `PATH` for the changelog and `manage-release` steps. The download is gated on `build-cli` succeeding; when that callback is skipped, finalize falls back to the pinned `setup-cli` install so the changelog step still finds cascade on `PATH`. Cascade is self-hosting, so a new CLI capability must be usable in the same run that ships it.

Scope

Gated entirely on the existing own-repo generation path (`WithOwnRepoRelease()` / the `--own-repo` flag). Downstream (user) orchestrate output stays byte-identical to `main`: users install a pinned released cascade through `setup-cli` and never build from source. Proven by an empty `git diff origin/main` on `internal/generate/promote.go`, `.github/workflows/promote.yaml`, and the `manage-release` action, plus the plain-generation regression test and scenario 47.

How the binary is sourced

Reused the existing `build-cli` from-source build (added a `cascade-cli` artifact upload) rather than a duplicate `go build` in finalize.

Verification

• `go build ./...`, `go test ./...`, `go test -race ./internal/generate/`, `golangci-lint run` all clean.
• `cascade verify --own-repo --config .github/manifest.yaml`: `3 files, no drift`.
• `actionlint` on the changed workflows adds no new findings over `main`.
• `e2e` module builds and vets; docs site builds.
• New generator unit test plus scenarios 46/47 assert the own-repo from-source bootstrap and the unchanged downstream pinned install.

Re-validated on a real rc after merge: one Release run, one fleet run, zero orphan drafts, finalize `--tag-only` works.

[joshua-temple]

E2E shard 4 failure investigated and fixed (pushed d52b207).

Root cause: not a generator regression. Scenario 47's added assertion checked for the literal substring `stablekernel/cascade/.github/actions/setup-cli@` in the generated orchestrate.yaml, but the e2e harness's `localizeWorkflows` step (e2e/harness/harness.go) unconditionally rewrites every such reference to a local `./.github/actions/X` path for every scenario, before any assertion runs. That substring can never survive localization, so the check could never pass regardless of what the generator emits.

Proved the real generator output is unaffected: built origin/main's binary and this branch's binary, generated plain (non-own-repo) orchestrate.yaml from the identical manifest with each, and diffed them byte-for-byte identical.

Fixed scenario 47 to assert the Setup CLI step's presence plus the absence of the own-repo-only build-cli if-gate and from-source download lines (localization-safe). Reran scenarios 46 and 47 against the real act+gitea harness locally: both pass. Full inner loop (build, test, race on internal/generate, golangci-lint, e2e build/vet) is green, `cascade verify --own-repo` is clean, and the downstream byte-diff against origin/main is still empty.