feat(server): add create_bug and add_attachment

[plusky]

Two write tools the server did not have: filing a bug, and uploading an
attachment to one.

Filing needed a gate the guard had no shape for

Every existing check asks may this client touch that bug? — a bug being filed
does not exist yet. So the bug as requested is classified against the same
rules, with one exception that decides how much the mechanism is worth.

Bugzilla augments what the request asks for. It unions the product's
mandatory groups into the new bug, so a client's claim about groups can only
ever under-state the result. Trusting it inverted the guard:

payload	old behaviour
groups omitted	Unknown → denied (fail closed, correct)
groups: ["security-embargo"]	denied
groups: ["partner"]	allowed — then Bugzilla adds security-* and the bug is one the policy hides

Supplying a field was strictly more permissive than omitting it. may_create
now treats groups as unknown whatever the payload says. The consequence is
stated plainly rather than engineered around: a policy whose rules consult
groups refuses all creation, because what the bug will look like cannot be
known before it exists. Every other create field is taken verbatim by Bugzilla
or the create fails upstream, so those claims are evidence and are trusted.

The prospective bug is dated now, so an age rule refuses creation wherever
it would immediately hide the result.

Both refusals are indistinguishable

Guard refusal and upstream refusal return the same text and cost the same one
upstream request — the refused path burns a classify against bug id 0, the
padding precedent download_attachment already sets. Without it, a client
could send a deliberately invalid version so upstream always errored, and
read the policy off which refusal came back — field by field, creating nothing.
A successful create is still distinguishable, which is the tool working, and
it costs a real attributable bug.

Uploading

Gated by a new Attach capability, separate from the read-side
Attachments: an operator who lets a client read attachments has not agreed to
let it write them. Both new capabilities are writes, so read_only strips them
and delists both tools (I13). Uploads are held to the same
max_attachment_bytes ceiling as downloads, measured on the decoded length;
the refusal names no number, since the cap is policy (I1).

Upgrade note

Capability::ALL went 11 → 13, and an allow rule grants all of them — so
every existing deployment that allows anything gains bug filing and attachment
upload on upgrade. To keep the old behaviour: disabled_tools = ["create_bug", "add_attachment"], or convert allow rules to enumerated restrict.
Read-only deployments are unaffected. Documented in README and DESIGN.md.

The tests that were missing

The binary crate had no lib target, so nothing could drive a tool — and
three mutations that gut both gates (swapping the write capability for the read
one, dropping the may_create call, dropping the size check) passed the entire
suite. There is a lib target now, plus integration tests that stand up a real
server over an in-memory transport and call the tools through an MCP client
against wiremock, so a tool that stops calling its guard fails a test.

187 tests. Every fix mutation-verified, and I re-ran the two most important
mutations independently after the fixes: both now die.

Also fixed: add_attachment was sending Bug.update's {"comment":{"body":…}}
shape, but Bug.add_attachment documents comment as a plain string. And the
shipped examples/policy.toml advertised creation while its first rule made it
impossible — it now says so, and a test parses the shipped file to keep that
true.