docs: verify the base path on the real host

The real-host smoke test was the migration's #1 production-only failure mode and
had never run. It has now run, without taking the site down: the Astro dist was
published to `pages` additively under two previously-unused paths (`_astro/` and
`_verify/summary/`), so all ten live pages stayed up, then force-pushed away.

Astro's base-prefixed absolute asset URLs resolve on the Pages Server — that was
the actual risk, and it is now proven rather than assumed. Trailing-slash
redirects match `trailingSlash: 'always'`.

Also corrects two things the guide got wrong:

- a `?v=$(git rev-parse --short HEAD)` cache-busting idiom. The Pages Server
  caches for ten minutes keyed on path, so a query string never busted it; the
  guide was telling operators to trust a check that could not work. A file you
  just deleted keeps serving 200 until the cache expires.
- the claim that a push to `main` publishes. It no longer does, and must not
  until cutover.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/operations-guide.md

@@ -54,8 +54,8 @@ flowchart LR
   E[Edit main] --> V[pnpm run gate]
   V --> C[Commit]
   C --> P[Push main]
-  P --> G[Gitea Actions: gate + build]
-  G --> B[Force-push dist to pages]
+  P --> G[Gitea Actions: gate]
+  G -.manual dispatch.-> B[Build + force-push dist to pages]
   B --> S[Gitea Pages Server]
   S --> L[Live URL]
 ```
@@ -108,9 +108,16 @@ committing.
 
 ### 5. CI publication and its manual fallback
 
-On a successful `main` push, Gitea Actions builds `dist/` and force-pushes it to
-`pages`. This force-push is intentional: `pages` is machine-owned generated
-output, and no person or other workflow may write it.
+Gitea Actions builds `dist/` and force-pushes it to `pages`. This force-push is
+intentional: `pages` is machine-owned generated output, and no person or other
+workflow may write it.
+
+**For the duration of the Astro migration, publication is manual.** The
+`publish` job runs only from a `workflow_dispatch` with its `publish` input set
+to true — a push to `main` runs the gate and stops there. The reason: `dist/`
+currently holds three HTML files (`/summary/` plus the two `hands-on/` fixtures)
+against the ten pages the live branch serves, so publishing on every push would
+take the site down to a stub. Task 20 (cutover) makes it automatic again.
 
 This Gitea's act-runner registration is kept in an `emptyDir`. A pod restart
 silently removes the registration; if a site does not update, check and
@@ -135,7 +142,7 @@ git worktree remove /tmp/ai-for-dummies-pages
 
 ```bash
 curl -sS -o /dev/null -w '%{http_code}\n' \
-  "https://netcracker.pages.marcospaulo.dev.br/ai-for-dummies/summary/?v=$(git rev-parse --short HEAD)"
+  "https://netcracker.pages.marcospaulo.dev.br/ai-for-dummies/summary/"
 ```
 
 Also check a nested static asset; base-path problems usually appear on assets
@@ -143,9 +150,17 @@ first:
 
 ```bash
 curl -sS -o /dev/null -w '%{http_code}\n' \
-  "https://netcracker.pages.marcospaulo.dev.br/ai-for-dummies/hands-on/starter/?v=$(git rev-parse --short HEAD)"
+  "https://netcracker.pages.marcospaulo.dev.br/ai-for-dummies/hands-on/starter/"
 ```
 
+**The Pages Server caches for ten minutes** (`x-pages-cache: true`,
+`cache-control: public, max-age=600`), and the cache is keyed on the _path_. A
+`?v=$(git rev-parse …)` query string does **not** bust it — that idiom used to
+be in this guide and it never worked. After a publish, a URL can keep serving
+the previous content, or keep serving a file you just deleted, for up to ten
+minutes. Budget for that before concluding a deploy failed. Check
+`last-modified` and `etag` with `curl -I` to tell fresh from cached.
+
 The correct URL pattern is **owner subdomain + repository path**:
 
 ```text