feat(server): add product and field discovery tools

[mimi1vx]

Two self-contained commits, each verified independently (builds/tests/lints
clean on its own).

What

create_bug takes a fixed parameter set (product, component, summary,
version, description, severity, priority, op_sys, platform,
keywords, groups) and has no way to answer "which products may I file
into", "which components/versions does this product have", or "which fields
are mandatory on entry and what are their legal values" — the caller has to
already know. Nothing on the tool surface exposes that instance metadata.

• feat(core): add product and field discovery endpoints to the client —
  three new read-only BugzillaClient methods: enterable_product_ids
  (GET /rest/product_enterable), products (GET /rest/product, with
  ids/names/include_fields all optional), and bug_fields
  (GET /rest/field/bug[/{name}]). Same get_json/.without_url() auth and
  sanitization path as every other client call (I12); a missing/malformed
  envelope is an error, never a silently empty result.
• feat(server): add guarded product and field discovery tools — two new MCP
  tools, bugzilla_products and bug_fields. Both take no bug id (no guard
  capability applies, I8 doesn't apply), and both are exposed only when the
  operator sets a new global.allow_discovery = true policy key (default
  false); otherwise they're removed from the tool listing via the same
  ToolRouter::remove_route mechanism read-only mode uses (I13). Detail calls
  (naming specific products/fields) are capped at 5 names with a fixed
  refusal and zero upstream requests over the cap. default_assigned_to /
  default_qa_contact (account emails) are dropped by the server's own
  projection — an enforced omission, never an unenforced include_fields
  request.

Why the policy stays unfiltered here

Both tools return exactly what Bugzilla answers to the server's own key —
never filtered against the guard policy. Bugzilla already scopes product and
field visibility per key; filtering the catalog again here would itself be a
policy-enumeration oracle, the exact class of leak create_bug's padded
uniform refusal pays a wasted upstream request to avoid for a single product.
An operator who wants product or field names withheld simply leaves
allow_discovery off (the default), which removes the routes from the
listing entirely rather than serving a filtered — and therefore
information-leaking — catalog.

Invariants touched

• New I16: both tools are unfiltered pass-through of instance metadata,
  never bug data, no capability applies, removed from the listing unless
  global.allow_discovery = true.
• I8 — unaffected; explicitly does not apply (no bug id to assess).
• I13 — reused mechanism (ToolRouter::remove_route), same as read-only
  and disabled_tools.
• I12 — the new client methods share the exact same auth/sanitize path as
  every existing call; a dedicated wiremock suite asserts the key never
  appears in error text.

Verification

• cargo fmt --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo clippy -p bugwarden --features gen --all-targets --locked -- -D warnings
• cargo test --workspace --all-targets --locked — all green, including:
  • crates/bugwarden-core/tests/discovery_wiremock.rs (new): envelope
    shapes for all three endpoints, string- and number-encoded ids, a
    malformed envelope errors rather than returning an empty list, path
    percent-encoding for a field name containing /, no API key in error
    text.
  • crates/bugwarden/tests/tools_wiremock.rs: catalog vs. detail
    projection for both tools, default_assigned_to/default_qa_contact
    never appear in a response, the on_bug_entry_only filter, legal
    values present in detail but absent from the catalog, over-cap refusals
    make zero upstream requests, both tools absent from the listing by
    default and present under allow_discovery = true.
  • crates/bugwarden/src/server.rs unit tests: discovery tools
    absent/present per policy, a discovery tool name stays a valid
    disabled_tools entry with discovery off.
  • crates/bugwarden/tests/audit_wiremock.rs: the one-record-per-call
    guarantee (I15) extended to cover both new routes.
• cargo deny check — clean (no new dependencies).
• Each commit verified standalone in an isolated worktree (fmt, clippy,
  test) — both build and pass on their own, not just as a pair.
• Live-probed all four Bugzilla routes (product_enterable, product,
  field/bug, field/bug/{name}) against bugzilla.mozilla.org:
  product_enterable returns JSON-number ids there (not the string ids
  Bugzilla's own docs show as an example), which is why the client accepts
  both shapes; the other three endpoints matched the documented shape
  exactly.