A long-running services kind: declared ports, always on, placed on the owner's hardware, for a Minecraft network and its websites #1118

The owner is bringing the vxrail back and wants a Minecraft server network with great websites and supporting infrastructure, where the community contributes directly. Today an app is an HTTP process behind the forge's proxy that sleeps when idle. A game server is none of those things: it declares TCP/UDP ports, stays on, wants a specific machine, and its website is a separate app that reads its state.

Done looks like:

• [ ] forge.json kind: "service": declared ports (tcp/udp), always on, placement (a node label), resource limits, a health command; the forge runs it in a cell with those ports published, never proxied, and never puts it to sleep.
• [ ] A service's companion website is an ordinary app that reaches it over the forge's internal address and shows its status, players, and a tell box for the community.
• [ ] Community contribution: a public repository whose pulls from outsiders run in previews (the outsider gate already exists) and whose owner ships them; the crew answers reports.
• [ ] Rehearsal: a Paper or Fabric server as a service on the vxrail, a website app beside it, a friend joins, a pull from an outsider lands a change to the website.

Files I expect: src/apps/manifest.ts, src/apps/runtime.ts, src/apps/contain.ts (published ports), src/fleet/* (placement), docs/APPS.md.

Parked by the crew: the check failed and the decider saw no point in another try (pull #1367 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("the studio head says why the app is not up > a serving app with red tests still reads as serving, with the failure in its own words, and is still open-able") and the decider saw no point in another try (pull #1451 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed and the decider saw no point in another try (pull #1367 closed)
2. the check failed ("the studio head says why the app is not up > a serving app with red tests still reads as serving, with the failure in its own words, and is still open-able") and the decider saw no point in another try (pull #1451 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate (#595). This issue is labelled P9 Multiplayer, but P9 has no umbrella issue, so the forge refuses to plan work under it. With no pillar, it waits until the owner opens "P9 Multiplayer: …". Why both pulls failed: each one tried to do all of it in one run. #1451 also changed how the studio head reads a web app's state, which turned test/studio.test.ts red.

What is already on main: src/apps/service.ts reads and checks kind: "service" (TCP ports, always on, metal/cloud placement, volumes). Nothing runs it yet.

Once the P9 umbrella exists, this is the split, one run each, in order:

1. A service stays on. The runtime starts it at deploy, the idle reaper skips it, it is restarted with backoff when it exits, and test/studio.test.ts stays green.
2. Ports are published from the cell (needs 1). It is never proxied, a port clash is refused, and the app page shows host:port.
3. UDP and a health command (needs 2). The health command is an argv array, not a shell string. Three failures restart the service, and it reads as unhealthy.
4. Metal placement (needs 1). The service runs on the owner's node, or waits and says why.
5. Companion website (needs 2). An app names a service it uses, gets its internal address in an environment variable, and its egress allows only that.
6. Minecraft network template (needs 3, 4, 5). A Paper service and its website, plus the vxrail rehearsal as a checklist for the owner.

Every piece names its new test file in scripts/gate.ts.