P2: Add a load-test harness that runs against a real instance

Why

Every limit in docs/operations.md § Production baseline — concurrent clones, per-client clones, SSH connections, the read bound, the metadata quotas — was chosen from reasoning rather than measurement. Nothing in the repository can produce a number for them, so nobody can tell a limit that is too low (a slow clone) from one that is missing (an outage).

#1’s definition of done needs exactly those numbers: bounded memory, file descriptors, and process counts under a staging soak.

Scope

• A Go test behind a load build tag that starts a real server on a loopback port with a temporary data directory, following the pattern server/deployment_modes_test.go already uses. No new command and no new module.
• Seed one repository with enough shape to be realistic: a few hundred commits, files at several sizes, an issue and a change request with comments, an LFS object, and an attached artifact.
• Drive concurrent clients for a configurable duration and concurrency, with defaults small enough for a laptop and staging values documented.
• Report per scenario: requests, throughput, latency percentiles, and errors by status. Sample the server during the run for peak RSS, open file descriptors, goroutines, and child processes.
• One scenario to prove the harness end to end: an anonymous clone over HTTP.
• Keep it out of verify: the build tag means go test ./... skips it, and nothing in it ships in the binary.

Acceptance

• One documented command runs the harness and prints the table.
• Peak RSS, file descriptors, goroutines, and process counts appear in the output.
• go test ./... and verify are unaffected, and the harness adds no dependency to the module’s build.

Part of #14. Blocks the scenario issues that follow it.