feat(relay)!: remove built-in ACME

.oss-scanner/threat_model.md

@@ -19,7 +19,7 @@ Treat everything a peer sends as hostile, before and after authentication:
 The relay is deployed on the public internet as shared infrastructure: one process serves many unrelated tenants, most of them anonymous or holding a token from a third party's auth server. Attack these properties:
 
 - **Untrusted network input, bounded cost.** Whatever a peer sends, the memory, CPU, and state it makes the other side hold must be bounded. A peer that can grow relay memory or CPU without bound, past the configured per-session limits (`rs/moq-relay/src/limits.rs`), is a bug even when it takes many messages to do. Fan-out is the multiplier to look for: one publisher's bytes, or one subscriber's request, reaching many sessions or pinning cache.
-- **Encryption.** Every transport is TLS 1.3 via rustls with aws-lc: QUIC and WebTransport, and WebSocket over `[web.https]`. Certificates are loaded from disk, issued by ACME (`rs/moq-relay/src/acme.rs`, TLS-ALPN-01), or self-signed and pinned by the fingerprint at `/certificate.sha256`. Check whether the relay accepts 0-RTT, and if it does, whether early data can be replayed. Plain `[web.http]` is a documented development option, not a finding.
+- **Encryption.** Every transport is TLS 1.3 via rustls with aws-lc: QUIC and WebTransport, and WebSocket over `[web.https]`. Certificates are loaded from disk or self-signed and pinned by the fingerprint at `/certificate.sha256`. Check whether the relay accepts 0-RTT, and if it does, whether early data can be replayed. Plain `[web.http]` is a documented development option, not a finding.
 - **Authentication.** Sessions are admitted by a JWT (`moq-auth`, which accepts HMAC, RSA, ECDSA and EdDSA keys, so algorithm confusion and key selection are in scope), by an external auth server over HTTP (`doc/bin/relay/auth.md`), by a verified client certificate weighed by that server, or by a static anonymous grant. Expiry, revalidation, and in-band renewal must never extend a grant past what the server issued, and a failure to reach the auth server must refuse rather than admit.
 - **Multi-tenancy.** A grant's `root` scopes a session to one subtree; `mounts` add read-only views. A session must never publish, subscribe, receive announcements, fetch, or see stats outside its grant, whether through path normalization, pattern matching (`moq-pattern`), the HTTP endpoints, cluster forwarding, or a revalidation that changes the grant mid-session. One tenant must not be able to degrade another beyond its fair share, for example by exhausting a shared cache or a shared connection limit.
 - **Cache integrity.** The relay caches and forwards groups by broadcast, track, and group. A publisher must not be able to overwrite or inject into a broadcast it was not granted, and a subscriber must never receive one tenant's data under another tenant's name.