Cache Git LFS objects #517

The Git cache in #403 and #492 serves clones and fetches over the Git protocol only. For repositories that use LFS, every checkout still downloads its large files from the upstream, and those files are often most of the transfer.

LFS has a separate HTTP API: the client POSTs to {repo}/info/lfs/objects/batch with the object IDs it needs, the server returns a download href for each, and the client then GETs them. rolandjitsu/git-cache-proxy caches this in about 550 lines (src/lfs.rs). It forwards the batch request upstream, rewrites each href to point at the proxy, and serves object GETs from disk when it has them. On a miss it requests a fresh href for that object from the upstream batch API, downloads it, and checks it against its sha256 object ID before storing it.

LFS objects are immutable and named by their sha256, so they fit the existing artifact storage, including the S3, GCS and R2 backends, DirectServe and retention, whereas bare repositories are limited to local disk.

The open question is which hosts the proxy fetches from. Batch hrefs, and the redirects they lead to, often point at object storage on a different host from the Git upstream. Those fetches still need the existing address checks, and upstream.auth credentials must stay scoped to their hosts. The options are an allowlist of object hosts per Git upstream, or accepting any href the upstream's batch response returns.