A forge addressed by IP hands every app a hostname that is not a URL, and every app dies at boot #309

Pushed successfully.

Fixes #269: a forge reached by plain IP (the default when nothing sets FORGE_URL) was handing every app a FORGE_APP_URL like http://notes.127.0.0.1:3999 — not a URL, since WHATWG rejects a hostname whose last label is numeric unless the whole thing is an IPv4 address. The scaffold's own new URL(FORGE_APP_URL) in src/env.ts threw at import time, so every app died before it ever answered.

What changed:

• src/apps/host.ts: added domainHoldsAppHosts (does new URL() accept this domain once a slug attaches?) and resolveAppDomain, which decides the app hostname once at boot — an explicit FORGE_APP_DOMAIN is untouched either way; a loopback address (127.0.0.1, localhost, ::1) falls back to localhost, which parses and which browsers already resolve to loopback; anything else leaves apps off with a one-line message naming FORGE_APP_DOMAIN as the fix, rather than starting apps that are guaranteed to crash.
• src/main.ts: wires this in at the one place the domain was computed before.
• docs/APPS.md: a new paragraph under "Hostnames and the proxy" spelling out the IP case and what to set.
• test/apps-adversarial.test.ts: unit tests for domainHoldsAppHosts/resolveAppDomain covering localhost, forge.example, --forge.example, and IPv4 addresses (loopback and non-loopback), plus an end-to-end test that boots an AppsRuntime with the domain resolveAppDomain picks for a 127.0.0.1 forge and confirms a scaffolded app actually deploys and answers — the crash this issue reports, proven fixed rather than just asserted.

bun run check (tsc + the full sharded suite, 443 tests) passes. Left out: no change for a forge reached by a real, non-loopback IP beyond turning its apps off with the message — there's no hostname to fall back to that would resolve anywhere but the machine itself, so the operator has to supply one via FORGE_APP_DOMAIN.

Closes #269