fix(tools): run the publish guard as the committing user, not ci-runner

Documented with `sudo -u ci-runner`, copied from the neighbouring tools that
call the Gitea API. Wrong here: the guard fetches, fetching writes
.git/FETCH_HEAD, and that file belongs to the committing user -- so as
ci-runner it died with "impossibile aprire '.git/FETCH_HEAD': Permesso negato"
before comparing anything.

A guard that cannot run is worse than no guard, since the failure looks like
infrastructure noise rather than an answer. The question it asks is "does what
I have match what is published", so it belongs to whoever holds the working
tree.

docs/RUNBOOK-PhaseC.md

@@ -621,11 +621,15 @@ while a downstream repo chased a snapshot-name bug that was fixed locally.
 Check before announcing any action change as done:
 
 ```bash
-sudo -u ci-runner /opt/ci/venv/bin/python tools/ci-action-published.py
+/opt/ci/venv/bin/python tools/ci-action-published.py
 # OK   — .gitea/ matches origin/main; CI runs what you see here.
 # FAIL — lists the drifted files, exit 1
 ```
 
+Run it as the user who commits, **not** under `sudo -u ci-runner`: it fetches,
+which needs write access to `.git`, and `.git/FETCH_HEAD` here belongs to the
+committing user.
+
 It catches both ways of being unpublished, committed-but-unpushed and
 edited-but-uncommitted, and fetches first so it compares against the server
 rather than a stale remote-tracking ref (`--no-fetch` to skip the network).