Phase 7 slice 5: pages are a build directory you can publish

Phase 7 slice 5: pages are a build directory you can publish

A site is a branch, so managing one is managing a branch; the sugar is worth it
for one reason: a build directory is a snapshot, and a plain push from a branch
leaves deleted pages served forever.

- vole pages deploy [<dir>] replaces the branch's tree with the directory, as a
  normal commit on the tip, so a protected pages branch still goes through review
  and a lost push race re-applies the snapshot instead of merging two builds
- --dry-run reports added/changed/removed; a deploy whose files already match the
  published tree pushes nothing, because a build that reruns on every commit must
  not add an empty commit each time
- vole pages status reports tip, commit, file count and bytes; unpublish deletes
  the branch, which is what makes the site 404
- dotfiles are published (.nojekyll, .well-known), .git is skipped and symlinks
  are skipped rather than followed
- issueCLI became branchCLI with a ref field: issue commands and pages commands
  now share one fetch/CAS/push-with-retry path instead of two copies of it

The first version read the local branch as the truth, and the local branch
outlives an unpublish, so deploy said "already published" for a site that was
404ing and status called a dead site live. Both now ask the server with
git ls-remote; syncSiteRef prunes a local branch the server no longer has, so a
re-publish starts fresh instead of resurrecting the old history.

Measured through the binary against a real instance with pages_domain set: three
files deployed and served at demo.pages.test inside the one-second window, a
deleted file 404ing after the next deploy, re-deploy after unpublish in 325 ms,
status reporting 3 file(s) / 19 B, and unpublish twice as a no-op.