Badge: per-environment deployment badge (deployed version/status)

Problem

Status badges (#292) reflect run/build status. But "did CI pass" and "what's actually deployed" are different questions — and in gocdnext deployment is not a run event: it's a stage/gate inside a pipeline (approval → deploy job), and the authoritative state lives in deployment_revisions/environments, not runs.cause. A user who holds a manual prod-approval gate sees the build badge sit at running while nothing is actually building.

A deployment badge answers the CD question directly: what version is live in environment X.

Proposal

A per-environment deployment badge:

GET /api/v1/badge/{slug}/env/{environment}.svg?token=T

• label = the environment name (production, stage).
• message = the currently-deployed version (e.g. 10.1.19-abc), or a status word (deployed / pending / failed) when no version string is recorded.
• Reads the latest deployment_revisions row for (project, environment).

![build](https://<host>/api/v1/badge/example-app.svg?token=T)
![stage](https://<host>/api/v1/badge/example-app/env/stage.svg?token=T)
![prod](https://<host>/api/v1/badge/example-app/env/production.svg?token=T)

Scope

• New route + store query: latest deployment revision per (project_id, environment), gated by the same badge_token_hash as #292 (one token, multiple views).
• Render: variable-width message (the version string) — the current renderer already html.EscapeStrings everything; add a length cap (~32–48 chars + ellipsis) so a pathological version can't blow up the SVG.
• Docs: badge reference page.

Guardrails (security / performance / corner cases)

• New reflection surface: unlike the build badge (fixed status enum), this reflects the version string into the SVG. Keep html.EscapeString + add a hard length cap; the version is already validated on the deploy path (deploy.version allow-list), but cap defensively anyway.
• Disclosure: exposes the deployed version (slightly more than pass/fail) — same sensitivity class, opt-in, coarse; fine for the same audience that can already see the build badge.
• No oracle: unknown env / no deployment / bad token → the same unknown badge.
• Perf: indexed lookup of the latest revision per (project, environment); EXPLAIN ANALYZE in the PR.

Depends on / relates to

Builds on the #292 token/render/cache infra. Complementary to (not blocked by) the ?event= filter issue.

Start with the existing #292 badge token, render, and cache infrastructure, then trace the badge route and renderer. Inspect deployment_revisions and environments for the latest per-project environment lookup, and update the badge reference page; done means the new route returns the version or fallback status, uses the shared token, caps and escapes the message, and supports the documented cases.