Resolve a change request's head on the remote

Why

Closes #121. change new --head <branch> resolved the branch in the local clone. With a clone that was behind, the request recorded the old commit; when that commit was already in the base, the request contained nothing. That is how #117 merged nothing, closed #113, and left the stack on a side branch until it was caught.

What changed

• A branch’s head is resolved on the remote (git ls-remote) the metadata write pushes to, so the recorded commit is the tip the forge will review and land. When local and remote differ, the remote tip is recorded and stderr says so. A branch with no remote counterpart is recorded with a note that it is not on the remote yet. --no-push may fall back to the local ref when the remote cannot be reached; a caller that will push fails rather than guesses.
• A head already in the base is refused before anything is written: the same commit or an ancestor. The message is `nothing to review: is already in
• Tags and bare commits still pin the request to that commit, with no branch.

Tests

server/change_heads_test.go:

• the branch moves on the forge after the clone; the request records the remote tip, head_ref names the branch, and stderr explains the difference;
• --head main (equal) and --head <first-commit> (ancestor) are refused and write no request;
• change update <id> --head main is refused the same way;
• a local-only branch is created with a note, and records its local tip.

TestRequestAuthorComesFromTheKey now opens its request from a real topic branch, because a request whose head is the base is refused by design.

Checks

gofmt, go vet ./..., python3 scripts/check-links.py, ./vole workflow check, and the full -race suite with GOFLAGS=-tags=sqlite_fts5.