Restructure README Deployment section for multi-path peer documentation

[krisrowe]

Problem

The README's current "Cloud Deployment (Optional)" section is framed around a single deploy path (gapp + Cloud Run). The upstream design in echomodel/mcp-app#26 and echomodel/mcp-app#27 established that an mcp-app solution should document its multiple supported deploy paths as peers — stdio, gapp, bare gcloud run deploy --source ., future mcp-app deploy, etc. — without elevating one over the others.

monarch-access should follow that posture in its own README.

Starting point

Initial hunks for this restructure live on branch wip/readme-deployment-restructure — one commit that strips the existing stdio-registration subsections from the ## MCP Server for AI Assistants section and inserts a pointer to a future ## Deployment section. The stripped stdio content is meant to be restored inside the new Deployment section as a peer subsection to the HTTP paths.

The branch is WIP and should not be merged as-is. Pick up from there or redo the strip from main — either is fine; the branch is a convenience.

Proposed target structure

Replace the current "MCP Server for AI Assistants" + "Cloud Deployment (Optional)" sections with a unified "Deployment" section whose subsections are the supported paths, each as a peer:

## Deployment

monarch-access can deploy via any of the paths below. Each is
documented as a peer — none is canonical. Pick the one that matches
your environment.

### Runtime contract

<existing env-var table + endpoint paths + start command>

### stdio (local MCP client subprocess)

<stdio registration commands for Claude Code + Gemini CLI, and the
user-profile setup for the 'local' user via monarch-admin>

### gcloud run deploy (bare, source build)

<if Procfile ships: "gcloud run deploy --source ." with env-var flags
and secret + volume setup>

### gapp deploy (GCP Cloud Run via gapp)

<existing gapp deploy walkthrough, mostly as-is>

### mcp-app deploy (when provider is available)

<placeholder referencing future mcp-app-cloudrun provider, with a
note that this section will expand once the provider exists>

Dependencies and ordering

1. Depends on a decision about whether to ship a Procfile (see separate issue). If no Procfile ships, the "gcloud run deploy (bare)" subsection becomes "gcloud run deploy with --command" and is clunkier; still worth documenting as a path.
2. Depends on echomodel/mcp-app cutting a release that includes the App-as-ASGI-callable change from echomodel/mcp-app#28 before the "mcp-app deploy" subsection becomes concrete. Until then, that subsection can be a placeholder noting the future path.

Both dependencies are soft — the restructure can ship with a good "gcloud run deploy with --command" recipe and a placeholder for mcp-app deploy, and then tighten later.

Work breakdown

• Finalize the section ordering and subsection scope
• Write the Runtime contract subsection (mostly lift from existing content)
• Write the stdio subsection (monarch-admin connect local + users add local, then claude mcp add and gemini mcp add stdio registration commands)
• Write the "gcloud run deploy" subsection (bare if Procfile ships, --command-based otherwise)
• Rewrite the gapp subsection under the new heading
• Add a placeholder for "mcp-app deploy" with a pointer to the mcp-app cloudrun provider status
• Update cross-references from earlier README sections (e.g., "MCP Server for AI Assistants" currently has a pointer line to #deployment)
• Remove the old "MCP Server for AI Assistants" and "Cloud Deployment (Optional)" headings in favor of the unified structure

Notes

This is content-only — no code changes, no behavior changes. Entirely a documentation restructure to reflect the multi-path posture blessed upstream in echomodel/mcp-app#26 and #27.