Document Labyricorn refresh dispatch

.labyricorn/AGENTS.md

@@ -50,9 +50,19 @@ those directories.
   command example.
 - Do not claim that content is public merely because a push succeeded. Report
   push status and synchronization/publication status separately.
-- When an authenticated refresh mechanism is implemented and documented, use
-  only its approved wrapper command and request at most one refresh for a pushed
-  commit. Until then, do not invent or bypass a trigger mechanism.
+- After an explicitly authorized push that changes `.labyricorn/`, request at
+  most one refresh through the site repository's documented Gitea
+  `workflow_dispatch` endpoint. Use `POST` with `{"ref":"main"}` and an
+  `Authorization: token ...` header supplied from the approved
+  `LABYRICORN_REFRESH_TOKEN` environment or credential store.
+- The endpoint is
+  `https://git.labyricorn.com/api/v1/repos/Labyricorn/labyricorn-site/actions/workflows/deploy.yml/dispatches`.
+  Never place its credential in the URL, this repository, an `AGENTS.md` file,
+  output, or logs. If the credential is unavailable, do not improvise: the
+  scheduled synchronization runs every 30 minutes.
+- A successful dispatch only queues synchronization. Verify the Action result
+  and the imported revision on the public project page before reporting that
+  publication completed.
 
 ## Validation and handoff
 

.labyricorn/README.md

@@ -34,4 +34,7 @@ Rules:
 
 The Labyricorn synchronization job reads content from an exact repository
 commit. Editing these records does not itself deploy the site; scheduled
-synchronization is the publication fallback.
+synchronization runs every 30 minutes and is the publication fallback. After an
+authorized push, an assistant with an approved refresh credential may dispatch
+the Labyricorn site's `deploy.yml` workflow once as documented in
+`.labyricorn/AGENTS.md`; the credential must never be stored in this repository.