fix(web): move the app origin off 6276, bound the publish route

Copilot review round 2 on #2100, plus a collision the review did not find.

The default app-origin port was 6276 — which is already
RUNNER_OAUTH_CALLBACK_DEFAULT_PORT, the CLI/TUI loopback OAuth callback.
That port is fixed precisely so an OAuth app can pre-register
http://127.0.0.1:6276/oauth/callback, which makes it the one listener here
that cannot move when something takes it first. A running --web would hold
it and break a later --cli/--tui OAuth flow at its registered redirect URI,
and docs/mcp-app-review.md has those two running side by side. This
listener has a documented dynamic fallback, so this listener yields: the
default is now 6278 (6277 skipped — v1's retired proxy port, which the
migration guide tells people to stop forwarding). A test asserts the two
defaults stay distinct.

Review comments:

- POST /api/app-document now applies hono's bodyLimit BEFORE parsing. The
  8MiB check ran after c.req.json() had buffered and parsed the whole
  request, and bounded only `html` — so bulk in `csp`, or in keys the route
  never reads, was fully materialized before the 413.
- `csp` is validated as an HTTP header value and length-bounded. The
  controller hands it to res.writeHead() verbatim, where Node throws
  ERR_INVALID_CHAR synchronously — inside the handler for a later,
  unrelated request, outside this route's error handling.
- The app-origin port now propagates everywhere the other two do: the CLI
  --print-handoff port-forward command (and its test), the Dockerfile's ENV
  and EXPOSE, and the remote-review SSH recipe in docs/mcp-app-review.md.
  Without it an app declaring _meta.ui.domain is unreachable through every
  documented remote workflow.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0177mPHAdECD18nLLCTwR5rh
Signed-off-by: cliffhall <cliff@futurescale.com>

docs/mcp-app-review.md

@@ -159,11 +159,11 @@ launching.
 ## 6. Reaching the web inspector remotely (SSH port-forward)
 
 When the backend runs on another host and you want to complete OAuth or
-visually inspect a rendered App from your local browser, forward **both**
+visually inspect a rendered App from your local browser, forward **all three**
 ports:
 
 ```bash
-ssh -L 6274:127.0.0.1:6274 -L 6275:127.0.0.1:6275 <remote-host>
+ssh -L 6274:127.0.0.1:6274 -L 6275:127.0.0.1:6275 -L 6278:127.0.0.1:6278 <remote-host>
 ```
 
 Then open `http://127.0.0.1:6274/?MCP_INSPECTOR_API_TOKEN=$TOKEN` locally.
@@ -178,6 +178,11 @@ Then open `http://127.0.0.1:6274/?MCP_INSPECTOR_API_TOKEN=$TOKEN` locally.
 - Forward `:6275` (`MCP_SANDBOX_PORT`) as well: the Apps tab renders widgets in
   an iframe served from that second origin; without it the App frame stays
   blank.
+- Forward `:6278` (`MCP_APP_ORIGIN_PORT`) too, for an App whose UI resource
+  declares `_meta.ui.domain` (#2056). That App is served from a *third* origin
+  the browser loads directly, so without the forward its frame fails to load —
+  and the backend cannot detect that, since publishing succeeded on its side.
+  An App that declares no `domain` is unaffected.
 - Forward the **same** local port number you bind on the remote — the browser
   sends `Origin: http://127.0.0.1:<local-port>` and the backend compares it to
   its own port.