Problem

Two DoS vectors in UploadPackV2:

1. `Filter.sparse_include?/3` reads a client-specified blob (`filter sparse:oid=`) with no size limit. A malicious client can point it at a multi-GB blob and force the server to load it into memory on every filtered request.

2. `UploadPackV2` has no ceiling on generated pack size. A pathological `want` set could build a huge pack in RAM before sending.

Both are observable from a bare `git` client with no special setup.

Fix plan

• Bound `sparse:oid` blob reads to `repo.max_object_size` or a dedicated `max_sparse_spec_size` (default 256 KiB). Reject oversized specs with `{:error, :sparse_spec_too_large}` which becomes a protocol-level error reply.
• Add a `max_pack_bytes` config on `Repo` (default 2 GiB, configurable). When `Writer.generate` would exceed it, abort with a structured error that the handler converts into a proper protocol error reply instead of letting the VM OOM.
• Full streaming pack writer is deferred to a separate issue; the size cap is the backstop for now.

Acceptance criteria

• Two new unit tests: oversized sparse blob is rejected with `{:error, :sparse_spec_too_large}`; oversized pack request is rejected before memory exhaustion.

Context

Originally item #2 of the grading-follow-up plan from PR #20.