Phase 5: file locking, for the repositories git cannot merge

Phase 5: file locking, for the repositories git cannot merge

`git lfs lock <path>` works over the SSH transfer, and while a path is held a
push that changes it is refused. This is what makes a repository of design
files usable by more than one person: two people pushing changes to the same
binary leaves one version and silently discards the other, and "discarded" is
not a conflict anybody can resolve.

The HTTP locking API is the usual path for git-lfs, and it is a *write*
surface, which this instance does not have — its web is anonymous and
read-only. So locking rides the SSH transfer protocol instead (lock,
list-lock, unlock, advertised as the `locking` capability): the key that
pushed is the key that locks, with no second endpoint and nothing new to
authenticate.

The decision worth remembering is where the refusal lives. git-lfs enforces
locks on the *client* — it asks the server what is held and declines to send
the push — which is a courtesy, and a plain `git push` walks straight past
it. So the rule also sits in pre-receive, at the one place this forge
enforces everything else, where a client setting cannot turn it off. The
client-side check becomes a faster error message rather than the authority.
It guards only the paths the push actually writes, so reading, branching and
merging untouched history are unaffected. An admin may override, audited, for
the same reason force-push is allowed: a lock whose holder has left would
otherwise make a path unpushable forever.

Locks live in data/users.db beside the roster and the access rules — the file
holding what git cannot rebuild — because a lock resurrected from history
would be exactly wrong. The point of a lock is that it is released. They are
keyed by account id, so a rename releases nothing, and path normalization
makes "./art.psd" and "art.psd" one lock rather than two.

/r/<repo>/locks answers "who is holding what", which the protocol otherwise
hides completely: the next person to push is refused with no way to find out
why without asking somebody.

Measured: TestALockRefusesAPushUntilItIsReleased drives the whole lifecycle
through the binary over SSH — lock, a refused push naming the holder, unlock,
the same push landing — with git-lfs deliberately absent so the refusal can
only come from pre-receive. TestLocksAreAdvertisedOnlyWhenOffered pins that
the capability follows the lock table, since a client that reads `locking`
will offer a command that must work. Store tests cover path normalization,
paging, owner partitioning and the audited override.

Known gap, stated rather than assumed: git-lfs is not installed here, so the
protocol was written against docs/proposals/ssh_adapter.md and verified with
a client written to that document — not with a shipped client. The framing,
the 201/409 argument blocks and the five-line lock-spec records are the
spec's; whether a real `git lfs lock` agrees is the first thing to check on a
machine that has one.