Correct the deploy timing: Pages is cached, not instant

Observed the public URL serving the previous build for ~3.5 minutes after a
push. Responses carry x-pages-cache: true and cache-control: max-age=600, and
a cache-busting query does not bypass it. The earlier claim of ~15s was wrong.

AGENTS.md and deploy.sh now say to check the repo raw file FIRST: if that
matches the local build the push landed and only the cache is behind, so don't
start changing things.

AGENTS.md

@@ -149,14 +149,26 @@ Two deliberate choices: the **area maps keep a white background** (they reproduc
 ./deploy.sh "what changed"
 ```
 
-Builds, commits, pushes to `pages`. Pages redeploys in ~15s. Verify with:
+Builds, commits, pushes to `pages`.
+
+**Do not expect the live site to update immediately.** Pages sits behind a cache
+(`x-pages-cache: true`, `cache-control: public, max-age=600`), so the public URL can serve the
+previous build for several minutes — observed between ~15 seconds and ~3.5 minutes. A
+cache-busting query string does not bypass it.
+
+When the live copy looks stale, **check the repo before debugging the deployment**:
 
 ```bash
-curl -s -L https://rain.pages.melonbread.xyz/la-li-lu-le-lo/ | sha256sum
+# 1. did the push actually land? (this is the source of truth)
+curl -s https://git.melonbread.xyz/rain/la-li-lu-le-lo/raw/branch/pages/index.html | sha256sum
 sha256sum index.html
+
+# 2. then, once those match, wait out the cache on the public URL
+curl -s -L https://rain.pages.melonbread.xyz/la-li-lu-le-lo/ | sha256sum
 ```
 
-The two must match. A stale deploy is the most common confusing failure — check the hash before debugging anything else.
+If (1) matches and (2) does not, it is the cache — wait, do not start changing things. If (1)
+does not match, the push failed and that is the real problem.
 
 ## Conventions