feat(api): speak Mercure 1.0 with a custom FrankenPHP binary

[BySplashGm]

Migrates the api/ stack to Mercure 1.0, which needed the hub it runs to be replaced
first.

Depends on #7 (api/ dependency bump) — symfony/mercure-bundle ^0.5 is what
introduces protocol_version.

The stock image cannot speak 1.0

$ docker run --rm dunglas/frankenphp:1-php8.5 frankenphp build-info
dep  github.com/dunglas/mercure        v0.24.2
dep  github.com/dunglas/mercure/caddy  v0.24.2
dep  github.com/caddyserver/caddy/v2   v2.11.4

0.24.2 is not a compatibility-mode fallback: compatibility mode is a 1.0 binary
relaxing its validation. 0.24 simply speaks 0.x, so a 1.0 configuration is rejected
by the module actually running, and no amount of config gets api/ onto the new
protocol.

So a builder stage rebuilds the binary against mercure/caddy@v1.0.0-alpha.3. The
recipe is the one documented at https://frankenphp.dev/docs/docker/ — which already
lists mercure/caddy and vulcain/caddy; only their versions are pinned here. Both
things that made this look expensive turned out to be free:

$ docker run --rm --entrypoint sh dunglas/frankenphp:1-builder-php8.3 -c 'go version'
go version go1.26.7 linux/arm64

Go 1.26.7 clears the go >= 1.26 floor that the 1.0 module declares — the floor that
made caddy:2.8-builder fail in the test-server image. And the build-info above
already pins Caddy 2.11.4, the version that module wants, so there is no Caddy
conflict to resolve.

Hub configuration

• transport_url bolt:///data/mercure.db → a transport bolt { path … } module
  block. The connection-string form still parses but is the deprecated path.
• publisher_jwt / subscriber_jwt move into an issuer block. They still parse,
  but in 1.0 they select compatibility mode, which relaxes access-token validation —
  not something to enable by accident.
• resource_identifier is pinned instead of derived per request. Ending it in
  /.well-known/mercure also makes it the base URL that relative topics and URL
  Patterns resolve against.

Token configuration

protocol_version: '1.0' switches the bundle to RFC 9068 access tokens, and it
refuses to compile without iss, sub and client_id. The issuer is read from
MERCURE_JWT_ISSUER by both the bundle and the hub, so the token's iss and the
trusted issuer cannot drift apart. aud is left at its default — the hub
public_url — which is exactly what resource_identifier pins.

---

Verification. Built, booted and exercised end to end.

$ docker compose exec php frankenphp build-info | grep -E 'mercure|caddy/v2'
dep  github.com/caddyserver/caddy/v2         v2.11.4
dep  github.com/dunglas/mercure              v1.0.0-alpha.3
dep  github.com/dunglas/mercure/caddy        v1.0.0-alpha.3

The container starting is the Caddyfile's own test — transport bolt { path }, the
issuer block and resource_identifier all parse and load. debug:container shows
the Hub service receiving ProtocolVersion::V1, and the token the bundle mints is
the RFC 9068 shape:

{"typ":"at+jwt","alg":"HS256"}
{
    "iss": "https://localhost",
    "sub": "esa-api", "client_id": "esa-api",
    "aud": "https://localhost/.well-known/mercure",
    "authorization_details": [
        {"type": "https://mercure.rocks/authorization-detail",
         "actions": ["publish"], "topics": [{"match": "*"}]}
    ],
    "iat": 1788512949.415001, "jti": "…", "exp": 1788516549.415018
}

Publishing with it returns 200 and an update id. Subscribing anonymously with
?match_urlpattern=/authors/:id returns 200 text/event-stream.

jwt.publish: ['*'] is translated as expected: MercureExtension.php:148 builds
new Grant([Grant::ACTION_PUBLISH], $hub['jwt']['publish']), and the empty
subscribe grant the bundle always adds is inert under 1.0 — it does not reach the
token.

Two things found along the way, neither blocking this PR:

• Nothing in api/ publishes to Mercure yet. mercure.hub.default lands in the
  container's removed-ids.php — no consumer, so it is inlined away. No
  ApiResource sets mercure: true and no service injects HubInterface. That is
  why the 0.x configuration never bothered anyone. The migration is correct but not
  yet exercised by the application itself; a resource has to opt in for updates to
  flow.
• The bundle mints iat/exp as floats. RFC 7519 permits a non-integer NumericDate
  and the hub accepts it, so this is legal, just surprising.