Korifi build and release targets (not usable until Korifi auth lands)

[nabramovitz]

Warning

Not usable for real deployments yet. A console deployed to Korifi serves the UI but cannot log anyone in: Korifi has no UAA, and Stratos's CF auth assumes one (it takes Korifi's login root link and POSTs to a /oauth/token that doesn't exist). Bearer-token auth for Korifi endpoints is the subject of #5489. This PR only lands the build/packaging plumbing so that work can be developed and tested against a real Korifi.

What

Adds a Korifi flavor of the CF release flow:

• make build korifi — statically linked cgo jetstream for linux/<host-arch> (override with PLATFORM=linux/amd64), built with zig cc -target <arch>-linux-musl. Runs go generate ./... first so builds from fresh worktrees don't silently drop the generated plugin registration.
• make release korifi — stages dist/korifi-package/ and stratos-korifi-<version>.zip via a new korifi mode in build/release-cf.sh.

Existing flows are untouched: bare make release still means cf+github, and make release cf output is byte-identical.

Why the differences from the classic cf package

• Korifi has no binary_buildpack (Paketo only), so the manifest uses paketo-buildpacks/procfile with the package's existing Procfile.
• Korifi runs droplets on the Paketo jammy run image, which cannot exec a dynamically linked cgo binary (no glibc loader at the expected path), and the sqlite driver needs cgo — hence the static musl build. The release script refuses a dynamically linked binary in korifi mode with a pointer to make build korifi.
• The CF API address jetstream infers from VCAP_APPLICATION may not be reachable from inside the cluster (on kind it is localhost, i.e. the app pod itself), so the manifest defaults CF_API_URL to the in-cluster korifi-api-svc service. See Ensure VCAP_APPLICATION/cf_api can be used from both outside the cluster and within an app workload pod korifi#2299.
• The manifest's ENCRYPTION_KEY is generated at packaging time and cached in dist/.korifi-encryption-key (0600, gitignored, survives make clean) — no shared hardcoded key, and repackaging doesn't orphan data encrypted under a previous key.

Testing

Verified end to end against Korifi v0.18.0 on kind (arm64): make build korifi && make release korifi, cf push from dist/korifi-package/ — stages with the procfile buildpack, starts, serves the console UI, and fails login in exactly the way #5489 describes.

Two Korifi quirks hit while verifying, for the record: pushing over a crashlooping app never replaces the running droplet (filed as cloudfoundry/korifi#4378; cf restart recovers), and cf delete keeps routes, so a re-push with default-route needs cf delete-route first.

Refs #5489.

[norman-abramovitz]

LGTM