caddy: pin unmerged WebTransport PR #7669 via --replace, with snapshot versioning

[passcod]

🤖 Switches the Caddy build from a fixed upstream release (v2.11.4) to stock Caddy master with the unmerged WebTransport PR (#7669) injected via --replace, and introduces an apt-monotonic snapshot version scheme.

Why

We want Caddy to terminate/reverse-proxy WebTransport on the same HTTP/3 socket it already serves (to expose an HTTP backend over WT with self-signed, hash-pinned certs where WebPKI/custom-CA trust isn't feasible). That capability is #7669, which isn't in any tagged release yet. We already carry the certmagic fd-passing fix the same way, so this just adds a second --replace.

I verified #7669 applies to current master with no conflicts, and that the resulting tree builds, vets, and adapts enable_webtransport correctly.

How the patch is sourced

#7669 is unmerged, so its commits live only on the author's fork. We pin the exact PR-head commit (CADDY_REF in the workflow), rather than track a branch:

• A pinned SHA is immutable — go.sum records its hash, so a force-push / rebase / delete on the source can't silently change what we build, and integrity is guaranteed.
• Bumping it (newer master, or a newer revision of #7669) is a deliberate, reviewed edit to CADDY_REF in a PR here — same model as the certmagic pin.
• No fork of ours to maintain. Residual risk is availability only (if the source repo vanishes before Go's proxy caches the commit); if that ever bites, mirror the commit and repoint CADDY_REPO.

Versioning

Builds are versioned {base}+git{count}.{sha}-bes{rev}, e.g. 2.11.4+git25.13a4c3f4-bes1:

• {base}+git{count}.{sha} describes the upstream master commit #7669 sits on (merge-base), so the count is immune to the size/shape of the PR's own commits.
• + sorts after the base release, so our snapshot supersedes stock upstream in apt; {base} advances on its own as upstream tags new releases on the master line.
• -bes{rev} (BES_REV) is our packaging/patch revision, bumped when the patch or packaging changes but the upstream base hasn't moved.

Workflow header comments document which knob to turn when, and how to unwind each patch: once #7669 ships in a release, drop the version job + the caddy --replace and revert to a plain xcaddy build vX.Y.Z; the certmagic --replace (now pinned to the v0.25.4 release, which carries certmagic#380) drops once the Caddy we build requires certmagic >= v0.25.4.

Verified

The version-derivation logic, run against the canonical repo + the pinned #7669 commit, yields 2.11.4+git25.13a4c3f4-bes1 and confirms the commit is reachable. The full CI run is unproven here (no runner), but there is no longer any external prerequisite for it to succeed.