Add a load harness behind the load tag

Add a load harness behind the load tag

Every limit in the operations guide was chosen from reasoning. The harness
is what replaces that with a number: a real server on a loopback port with
a temporary data directory, seeded with a repository that has history,
files at several sizes, an issue and a change with comments and an
approval, and a release artifact in the LFS store.

One scenario proves it end to end: anonymous shallow clones over HTTP.
Each iteration probes `info/refs` so a refusal is reported as the status
it was refused with, then clones. Workers run until the configured
duration, and the report gives requests, throughput, p50/p90/p99 latency,
statuses, failure reasons, and the peak of RSS, file descriptors,
goroutines and the server's git child processes.

It is behind `//go:build load`, so `go test ./...` and the verify workflow
never run it, and nothing in it ships in the binary. The other read-path
scenarios in #100 add their own step functions to the same runner.

Run it:

  VOLE_LOAD_SCENARIO=clone VOLE_LOAD_CONCURRENCY=8 VOLE_LOAD_DURATION=30s \
    go test -tags load,sqlite_fts5 -run '^TestLoad$' -v ./server