split Deploy into a hub + 3 sub-pages; inline comments over annotations

The Deploy page got long and the code annotations rendered inconsistently
(some as (n) numbers, some as clickable +, and a marker on a fully-commented
line made that line vanish). Fix both:

- Deploy is now a HUB (docs/deploy/index.md): the intro + collision rule +
  central-deploy note, then card links to three focused sub-pages. Deploy
  stays the single global-nav entry; sub-pages are not_in_nav, reached from
  the hub cards.
  - deploy/compose.md — compose convention, storage tiers, how deploy fills
    it in, subprocess/browser knobs, checklist
  - deploy/dockerfile.md — services-account image, COPY, layer caching, uv
  - deploy/secrets.md — keeping secrets out of the image
- Replace code annotations with INLINE COMMENTS on the compose/Dockerfile
  examples: everything visible at once, no + to click, and the commented
  MOUNTS_DIR line no longer disappears.
- Update inbound links (index card, standards, workflow, environments) to
  deploy/ and deploy/compose.md; nav Deploy -> deploy/index.md with
  not_in_nav for the sub-pages.

Verified in-browser: hub cards link correctly, sub-pages render with visible
inline comments (0 annotation markers), left nav shows only Deploy;
mkdocs build --strict clean (validates not_in_nav + all cross-links).

Signed-off-by: disqualifier <dev@disqualifier.me>

docs/deploy/index.md

@@ -0,0 +1,54 @@
+# Deployment Guide
+
+> How a project gets onto **rethink-net** — our Ubuntu 26.x servers. Get your
+> container to follow a few consistent rules and deploying is mostly handing us a
+> `compose.yaml`.
+
+!!! tip "What can run here"
+    APIs, websites, applets, bots, monitors.
+
+!!! danger "Your compose names nothing repo-specific"
+    **No `container_name`. No hardcoded names, workspace, or `/srv` paths.** The
+    deploy layer injects identity and host paths at deploy time — your compose stays
+    generic so it can't collide with any other service on the fleet.
+
+    - service key is always **`svc`**
+    - named volumes use **bare names** (`cache`, not `myapp_cache`)
+    - host paths come from **`${LOGS_DIR}` / `${CONFIG_DIR}`**
+
+    Naming things after your repo used to cause **container-name collisions** at
+    fleet scale — two repos shipping the same name clashed. The generic compose
+    convention fixes that.
+
+!!! note "You don't run any deploy commands"
+    All services are deployed centrally by the ops tooling. You don't pick a host,
+    manage keys, or run anything — just make your repo follow the compose convention
+    and it's deployable. At deploy time the tooling **generates** the environment your
+    compose reads (`${LOGS_DIR}`, `${CONFIG_DIR}`, optional `${MOUNTS_DIR}`), so the
+    same file works locally and on the fleet.
+
+## The three things your repo needs
+
+<div class="grid cards" markdown>
+
+-   :material-file-cog: __[Compose convention](compose.md)__
+
+    ---
+
+    The `compose.yaml` your repo ships — generic `svc` service, the `${...}` host
+    mounts, storage tiers, and how deploy fills it in.
+
+-   :material-docker: __[Dockerfile & build](dockerfile.md)__
+
+    ---
+
+    The uid-agnostic image (services account 1337), getting files in with `COPY`,
+    layer caching, uv, and subprocess/browser workloads.
+
+-   :material-key: __[Secrets](secrets.md)__
+
+    ---
+
+    How secrets stay out of the image and reach the container read-only at runtime.
+
+</div>