Retroactive review followup: Fix API details and style nits in warm pools guide

[kcmartin]

Follow-up review fixes for the warm pools blueprint (#2427).

Technical:

• Use port 80 with the http handler for the Flycast service. Flycast is HTTP-only, and .flycast hostnames can't get public certs, so a tls handler on 443 would force clients to skip cert verification. This matches the config in the Connecting to User Machines blueprint.
• Drop min_machines_running from the Machine config example; it only has an effect when autostop is enabled, and this config sets autostop: "off" deliberately.
• Don't claim a specific 422 status for app-name collisions; neither our response-code docs nor the OpenAPI spec document one. The idempotent-retry advice is unchanged.
• The wait endpoint's 60s timeout is the documented default, not a maximum.

Links:

• Repoint the lease link to #create-a-machine-lease (the #machine-leases anchor doesn't exist) and drop the anchor on the exec link, since the exec endpoint isn't in the API reference yet. If we document exec (it's in the published OpenAPI spec), the original anchor can come back.
• Use canonical /docs/launch/processes/ instead of the /docs/apps/processes/ redirect.

Style, matching other blueprints: sentence-case "Pointers and footguns" heading, colon separators in Related reading.

Added missing entry for this guide on the side navigation

Not included here: documenting the exec and ip_assignments endpoints in the Machines API reference (pending confirmation that they're public and stable), and two open questions for Kyle, listed below (whether a 422/60s cap was observed in testing, and whether "network": "" in the Flycast allocation call is intentional).

[kcmartin]

Hey @kylemclaren, this is the follow-up from the retroactive review of your warm pools blueprint (#2427). The API usage is good overall (I checked it against the OpenAPI spec at docs.machines.dev). A few things that would be good if you can answer from your testing:

1. App-name collision status code: the guide said app creation returns 422 when the name is taken, but neither our response-code docs nor the OpenAPI spec mention 422. Did you observe that in your testing? If so we should add it to the reference; this PR softens the wording in the meantime.
2. Wait endpoint timeout: the guide called 60s the max, but everything we have documents 60s as the default. Did you hit a real server-side cap?
3. "network": "" in the Flycast allocation call: the app is created on a named network, so is the empty string intentional (meaning "use the app's own network")? If so, worth a line of prose saying that.

Related: exec and ip_assignments aren't in our Machines API reference at all, even though your guide leans on both and they're in the published API spec. Before we document them, can you (or the Machines folks) confirm they're considered public and stable?