deploy-the-site-by-handlisted

# Purpose Put the site live now, not after the Actions queue, without inventing a second way to publish. One command, the same one the Pages workflow runs, and the deploy is visible afterwards: the `gh-pages` commit and the site's footer both name the source commit. # When to use The operator says so, in words, in this session. A merge to master already deploys through the workflow; the hand deploy is for the cases where that is too slow, or the workflow is red for a reason that is not the site (a benchmark runner, a macOS job) and the site itself is green. Never deploy to make a red gate look green. # Procedure ## 1. Preconditions - You stand on the commit to publish, with a clean tree, and `origin/master` contains it. A preview of unmerged work is possible with `--any-ref`; the footer then names that commit, so nobody mistakes it for master. Say so when you do it. - `zola`, `node_modules` (`npm ci`) and, for the full gate, `cargo` are present; the script says what it skips. - GitHub Pages serves the `gh-pages` branch. Once per repository: `scripts/site-deploy --configure-pages` (needs `gh`); after that the setting stays. ## 2. Deploy ```bash scripts/site-deploy --dry-run # gate, build, check; shows the gh-pages commit it would push scripts/site-deploy # the same, then pushes gh-pages scripts/site-deploy --probe # add the browser probe (every route at 320, 390, 1280 px) ``` `just site-deploy` is the same command. The gate is: deriv