Hosted relay git push limited to ~5 MiB packs (code default 500 MB); over-limit and chunked pushes fail opaquely

## Summary

The hosted relay at `communities.buzz.xyz` accepts git pushes only up to ~5 MiB of pack body, which blocks seeding any real-world repo (ours is a ~210 MiB history). The relay code's own default for `BUZZ_GIT_MAX_PACK_BYTES` is 500 MB (`crates/buzz-relay/src/config.rs`), so the hosted deployment appears to run ~1% of stock. Requesting either a raise on hosted community relays or documentation that this is the intended hosted tier limit. Separately, the failure modes for oversized/large pushes are opaque enough that they cost us a full diagnostic session — two DX issues below.

All findings verified live on Buzz 0.5.2 against `firc.communities.buzz.xyz`, 2026-07-30, with NIP-98 auth working and small pushes succeeding throughout.

## 1. Hosted pack limit ~5 MiB (config request)

With client buffering fixed (see item 2), pushes of incompressible test blobs:

| Pack size | Result |
|---|---|
| ~5.0 MiB | success (4.5 s) |
| ~5.45 MB | TLS abort mid-upload (`LibreSSL bad record mac` / `broken pipe`) |
| 6, 8, 9, 10, 20, 25, 30 MB | same failure |
| 201.49 MiB real snapshot (5,526 objects) | HTTP 401 / curl 56 in ~2 s |

A single 25.4 MB tracked blob fails on its own, so multi-push chunked seeding cannot work around it — git can't split one blob. Cloudflare fronts the relay and is not the binding limit (its body allowance is far higher); enforcement matches `git_max_pack_bytes` in `api/git/transport.rs`.

**Ask:** raise `BUZZ_GIT_MAX_PACK_BYTES` on hosted community relays toward the code default (500 MB), or publish the hosted limit so operators can plan around it.

## 2. DX: pack over limit dies as a TLS abort, not a clean error

An over-limit push terminates mid-body with `curl 55/56, LibreSSL bad record mac` — no HTTP status reaches the client. A clean `413` (or a sideband error naming the limit) would have turned a multi-hour diagnosis into one error message.

## 3. DX: chunked Transfer-Encoding push fails with instant 401

git switches to chunked transfer for any push body over `http.postBuffer` (default 1 MiB). Against the NIP-98-authenticated endpoint this fails instantly with `HTTP 401 / curl 56` — the auth challenge can't be satisfied with a non-replayable chunked body. Workaround is `git config http.postBuffer 536870912`, verified (same 5 MB pack: fails chunked, lands buffered). Worth documenting prominently, or handling chunked bodies server-side, since every stock git client over 1 MiB hits this before ever seeing the real limit.

(Minor, observed while probing: sub-1MB requests intermittently drew `403` with a `__cf_bm` cookie — Cloudflare bot management challenging git's HTTP client. Mentioning it since it makes the failure surface look non-deterministic to operators.)

Start with crates/buzz-relay/src/config.rs and api/git/transport.rs, then review the hosted relay configuration and the documented http.postBuffer behavior. Reproduce buffered, over-limit, and chunked pushes using the reported pack sizes. Done means the hosted limit or its documentation is explicit and oversized or chunked pushes produce an understandable outcome.

Written by the indexing model from the issue text.