feat: allow the gateway to start remote nodes

[outofcoffee]

Today the gateway's wake only ever starts an engine on a daemon node. A remote environment is refused outright — remoteNode.StartWith returns "tell it what to serve with spinloop remote deploy" — and the gateway's wakeable computation skips every non-daemon node, so a request the fleet file allows it to wake never reaches a stopped remote node.

Allow the gateway to start a remote node, so a request reaches a stopped remote environment the same way it reaches a stopped local one: start it, hold the request until its engine answers, and route to it.

• A deployed-but-stopped environment is the bounded case: it already knows what to serve, so the gateway boots the instance (the existing start path), waits for the engine to answer, and routes — no deploy decision made in the request path
• Its WakeableModel comes from the environment's stored deploy config, named the way a running node reports it (served name first, then the model id), so a request matches it beside the daemon nodes it matches today
• A fleet whose wake is off still refuses, as it does now
• Undeployed environments are a separate question: they have nothing to serve yet, and the gateway starting one means choosing what to serve and paying for provisioning and weights — a heavier decision the current refusal keeps out of a request. Raise that on its own rather than folding it in
• Starting a remote instance costs money, unlike starting a local engine — decide whether waking a remote node needs its own opt-in beside the existing wake flag, so a stray request cannot boot a paid instance

Extends the gateway's on-demand wake with #153. The orchestrator's admission already treats a non-running node as a candidate when the fleet wakes (#188), so its items reach a remote node once the gateway can start one.