fetch-docs: pull and publish docs from CI (replaces buildbot doc rsync)

[grandixximo]

This is the doc fetch-and-publish step for the webserver, moved here from LinuxCNC/wlo#42 after discussion: it is operational, not website content, so it belongs in infrastructure alongside emc2-doc-build and rsync-*-wlo.

Background: since the doc build layout changed, linuxcnc.org/docs/devel stopped updating. CI now builds and uploads the docs as an artifact (LinuxCNC/linuxcnc#4150); this pulls and publishes it on the webserver, replacing the buildbot doc rsync.

fetch-docs is a cron-friendly, stdlib-only Python script. It:

• picks the newest non-expired linuxcnc-doc artifact built on the given branch by the trusted repo (head_repository_id, so a fork PR cannot inject docs),
• verifies the download against the artifact sha256 digest,
• sanity-checks the tree (index.html present, rejects PHP tags, executables, path traversal),
• swaps the served html symlink atomically and prunes to the live release plus one,
• skips if the live artifact is already deployed, silent on success.

Branch and webroot are arguments, so one cron line serves devel and one serves stable:

fetch-docs master /path/to/docs/devel
fetch-docs 2.9    /path/to/docs/stable

Trust model (per @BsAtHome): meant to run as a separately deployed, vetted local copy, not executed from a checkout. The token is read from a chmod-600 file (actions:read), branch and webroot are arguments, nothing operational is hardcoded.

Notes for whoever runs the server:

• WEBROOT, token path, and the cron schedule are set locally.
• The docroot must follow symlinks; the cron user needs write on the parent of the served path.
• This replaces the buildbot doc rsync, so worth confirming the handoff so the two do not fight over docs/ (an rsync --delete would clobber what this publishes).
• 2.9 only produces an artifact once Ci doc build backport 2.9 linuxcnc#4176 lands.

@andypugh @SebKuzminsky this is a starting point, happy to adjust paths, language, or trim.

[BsAtHome]

The token is read from a chmod-600 file (actions:read)

But it seems not verified that the token file actually has permissions 0600 (or 0400).

[grandixximo]

Good catch. The chmod 600 was only a hint in the comment, never enforced. It now stats the token file and refuses to run if any group/other bit is set, like ssh does for private keys.