Phase 7 slice 7: the build deploys the site

Phase 7 slice 7: the build deploys the site

pages: {path: site} on a job publishes that directory as the site branch, using
the same snapshot code `vole pages deploy` uses — a site published by a workflow
and one published by a person have to be the same commit shape, or the version
that drifts is the one nobody runs by hand.

- workflow: pages.path validated at push — one relative directory, no glob (a
  site is one tree), and only one job per workflow may declare it, since two
  publishers race and the winner is whichever runner finished last
- the directory is pinned into the queued run beside the steps and the artifact
  patterns; the branch comes from the server (pages_ref), which a workflow
  cannot know
- runner: after the artifacts, checks that the run's SHA is still the tip of its
  branch and refuses otherwise. Deploy is a snapshot, so a stale build finishing
  late would silently revert the site; the failure names both commits
- the site commit says where it came from: "site: main from run <id> (<sha>)"

Fixed on the way, caught by the end-to-end test: the shared push helper treated a
URL as a missing *named* remote, so a runner's deploy committed locally and
reported success while the site 404'd. A URL is now a remote in its own right.

Measured through the binary: two pushes queued two runs; the older one was
refused ("this run built f1f415ec but main is at 6beaa530 now; the site was not
deployed") and published nothing; the newer one deployed and the site host served
the new tree, with `git log pages` showing
"site: main from run 01M5MSC3... (6beaa530)".