fix(server): derive the http body cap from the attachment ceiling

[plusky]

Closes #52.

Two ceilings governed one thing without knowing about each other: the
transport's pinned 4 MiB POST cap and the operator's
global.max_attachment_bytes (decoded size). Above ~3 MiB configured, the
transport silently overrode the policy with a bare 413 — unrecordable, and
shaped like nothing else this server says.

The decided relationship

cap = clamp(ceil(max_attachment_bytes / 3) · 4 + 1 MiB, 4 MiB, 64 MiB)

• 4 MiB floor — non-attachment traffic and every policy at or below the
  2 MiB default behave exactly as before; 0 ("no policy cap") stays at the
  floor rather than becoming an unbounded body.
• 64 MiB ceiling — the memory bound holds for all policy values: a huge
  or fat-fingered cap clamps instead of deriving an effectively unbounded
  body. A decoded cap above ~47 MiB is therefore not honored over HTTP — the
  mirror of the 0 decision; both are documented.
• http_server_config is now a method on BugWarden, so the transport
  config reads the same guard the server enforces with — they cannot
  disagree by construction, and the integration harness exercises the same
  extraction main uses.

All three #52 acceptance criteria are satisfied, including the third: a 413
is documented as unrecordable (never reaches call_tool; same
pre-handler class as an auth refusal, #32), with the operator diagnosis
path written down.

Adversarial review before opening (three independent lenses)

Run against the uncommitted diff; every finding fixed before this PR was
opened.

Security — found the blocker. The first implementation saturated a huge
max_attachment_bytes to usize::MAX: an effectively uncapped POST body
buffered pre-guard — an OOM lever the old pin made impossible, violating
the derivation's own docstring. Fixed with the 64 MiB ceiling; the u64-
extreme tests now assert the clamp, and each extreme exercises a different
saturating step.

Correctness — found the unpinned term. Every test input was divisible
by 3, so replacing div_ceil(3) with floor division survived the whole
suite — the one term the change exists to get right. Now pinned with an
exact-equality test at 3 MiB + 1 (must derive 4 bytes more than floor
division yields). The review also verified the formula is the exact
padded base64 length, not merely a bound, and that Bugzilla's own
65535-character comment limit keeps worst-case framing inside the 1 MiB
headroom.

Docs — found the oracle. The 413 boundary is observable pre-auth:
probing body sizes recovers the derived cap and, above the floor,
max_attachment_bytes — a value two DESIGN.md sections deliberately keep
out of refusal text. Now recorded as an accepted trade-off with the
reasons (constant floor at or below ~2.25 MiB including the default;
what leaks is a memory-tuning number, not bug data — I1/I2/I3 untouched;
network reach is the access control until #32), cross-referenced from the
add_attachment non-disclosure note.

Notes also addressed: wrapped-base64 headroom erosion documented in the
helper (canonical encoders unaffected), README no longer overclaims the
guarantee, the test-inventory arithmetic reads correctly, and no rustdoc
links a private item.

Invariants

No guard weakened. I2/I3 do not apply to a 413 (no bug id, no filtered
count); I9 untouched (no CLI flag reaches the cap); I15's one-record scope
is tool calls, which a 413 never becomes — DESIGN.md now says so where the
audit decisions live. The one API change: http_server_config is no longer
a free function (pre-1.0 library surface).

Verification

cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo clippy -p bugwarden --features gen --all-targets -- -D warnings, cargo test --workspace --all-targets --locked (406 passed,
0 failed), cargo deny check — all green, run independently after the
review fixes landed.