Drop versioning from the documentation site

[dpol1]

Closes #274.

Zensical already shows the latest GitHub release in the repository card, so no separate build-time version label. First deploy from the next release, not 1.2: switch the Pages source to GitHub Actions when publishing it, then delete gh-pages.

[jnioche]

Looks great

The site the branch produces has been checked: zensical build --clean --strict passes with no
issues, the home page canonicalises to https://opensourcegreenops.cloud/, and sitemap.xml lists
all 17 pages at unversioned URLs.

Remaining work

Note to self

• Switch the repository publishing source to GitHub Actions. The repository is still set to
  publish from the gh-pages branch (build_type: legacy), so actions/deploy-pages cannot
  deploy. Change it under Settings, Pages, Source, or with
  gh api -X PUT repos/DigitalPebble/spruce/pages -f build_type=workflow. Note that the
  actions/configure-pages step in the workflow does not do this: its enablement input
  defaults to false and, even when enabled, needs a token other than GITHUB_TOKEN.

Improvements

• Add docs/src/robots.txt. There is currently no robots.txt at the root and no sitemap
  reference:

  ```
  User-agent: *
  Allow: /
  
  Sitemap: https://opensourcegreenops.cloud/sitemap.xml
  ```
  

• Add docs/src/CNAME containing opensourcegreenops.cloud. The custom domain is stored as
  a repository setting, and changing the publishing source is the point at which it is most
  likely to be disturbed. Losing it takes the site offline. Zensical copies both of these files
  from docs_dir into the build output verbatim, so they ship inside the artifact.

Workflow improvements

• Build with --strict (zensical build --clean --strict) so warnings such as a broken
  internal link fail the build instead of shipping. The branch already passes with it enabled.
• Rename the concurrency group from gh-pages to pages. No branch is involved any more.
• Print a message when the version guard trips. It currently fails on a bare non-zero exit
  from grep, which does not explain itself to whoever hits it.
• Decide whether to keep actions/configure-pages. It is close to a no-op here, since
  Zensical does not use its outputs. It is worth keeping only as an early, clear failure if
  Pages is not enabled.

Open question

• workflow_dispatch currently requires a release tag, so there is no way to publish a
  documentation-only fix without cutting a release. That is consistent with "the site describes
  the latest release", but it does mean a typo waits for the next one. An optional ref input
  falling back to the tag would allow both. Worth deciding deliberately.

After the first deployment

• Check that https://opensourcegreenops.cloud/ resolves and the TLS certificate is intact.
• Confirm the old URLs (for example /1.2/methodology/) now return 404.
• Submit the root sitemap.xml in Google Search Console and Bing Webmaster Tools, and request
  removal of the outdated versioned URLs so they drop out of the index sooner.
• The gh-pages branch can be deleted once the deployment is confirmed. Nothing reads it, and
  keeping it for a while is a cheap rollback path.

[dpol1]

Done in 60daf29: robots.txt, --strict, an error message on the guard, and the pages concurrency group.

Add docs/src/CNAME

Skipped: for a workflow deploy GitHub says "any existing CNAME file is ignored and is not required", the domain lives in the Pages setting (gh api repos/DigitalPebble/spruce/pages shows cname today). Worth rereading that field right after the switch.

Decide whether to keep actions/configure-pages

Kept, it is the step that fails early and clearly if the source is still gh-pages.

An optional ref input falling back to the tag would allow both

I'd keep tags only, a typo can go out as a patch release and the site keeps matching the card. Your call.