R3: split the landing into its own static container

- gateway/Dockerfile gains a `landing` target: caddy:2-alpine + the shared
  Vite build (identical build args keep the ui stage a single cached build);
  the gateway target drops landing.html from the embed.
- The contour caddy routes /app/, /telegram/ and the Connect path to the
  gateway; the catch-all — the landing at / and any stray path — goes to the
  new landing service, so junk traffic is absorbed by static file serving.
- deploy/landing/Caddyfile mirrors the webui caching (immutable assets,
  no-cache shells) and falls back unknown paths to the landing shell.
- The gateway's / now 308-redirects to /app/ (keeps a local no-caddy run
  usable); webui placeholder landing.html removed.
- CI deploy probe checks both / (landing) and /app/ (gateway).

Verified: both images build; the landing container serves landing.html at /
(no-cache) with junk-path fallback; the gateway image redirects / to /app/
and carries no landing content.

gateway/internal/webui/webui.go

@@ -1,12 +1,13 @@
 // Package webui serves the embedded static UI build over the public edge.
 //
-// The committed dist/ holds only placeholder index.html / landing.html so the gateway
-// module compiles with a plain `go build` (and in CI) without a UI build. The production
-// gateway image replaces dist/ with the real Vite build before compiling (see
-// gateway/Dockerfile), so the binary ships the UI inside it. Because Vite is built with a
-// relative asset base, one build serves under any path: the game SPA is mounted at /app/
-// (web) and /telegram/ (the Telegram Mini App), with a separate landing page at / — the
-// single-origin model in docs/ARCHITECTURE.md §13.
+// The committed dist/ holds only a placeholder index.html so the gateway module
+// compiles with a plain `go build` (and in CI) without a UI build. The production
+// gateway image replaces dist/ with the real Vite build — minus landing.html, which
+// ships in the separate landing container since R3 — before compiling (see
+// gateway/Dockerfile), so the binary ships the UI inside it. Because Vite is built
+// with a relative asset base, one build serves under any path: the game SPA is
+// mounted at /app/ (web) and /telegram/ (the Telegram Mini App) — the single-origin
+// model in docs/ARCHITECTURE.md §13.
 //
 // Caching (Stage 17): Vite emits hash-named files under assets/, so those are immutable and
 // cached hard (a reload/relaunch is a cache hit, not a re-download); the HTML shells carry
@@ -35,10 +36,10 @@ func distFS() fs.FS {
 }
 
 // Handler serves the embedded UI. An existing file is served directly (hash-named assets get
-// an immutable cache); every other path falls back to indexName (the SPA shell or the landing
-// page) so a client-side deep link still loads. When stripPrefix is non-empty it is removed
-// from the request path before lookup, so the same build serves under a sub-path (e.g.
-// "/app/" or "/telegram/").
+// an immutable cache); every other path falls back to indexName (the SPA shell) so a
+// client-side deep link still loads. When stripPrefix is non-empty it is removed from the
+// request path before lookup, so the same build serves under a sub-path (e.g. "/app/" or
+// "/telegram/").
 func Handler(stripPrefix, indexName string) http.Handler {
 	content := distFS()
 	files := http.FileServer(http.FS(content))