DESIGN.md's rmcp transport-default inventory omits two 3.1 knobs

[plusky]

The "rmcp 3.1 usage notes" section of docs/DESIGN.md states:

Two rmcp 3.1 transport defaults are set by name, not inherited (main.rs).

and then names allowed_hosts and max_request_body_bytes. Both are correctly
handled — http_server_config() (crates/bugwarden/src/server.rs) disables the
first deliberately and pins the second to the SDK's current value.

The problem is the word two. StreamableHttpServerConfig in rmcp 3.1.0 carries
two further knobs the inventory does not mention, so the sentence reads as a
complete account of the transport configuration surface when it is a partial one.

The unlisted knobs

field	default	why it matters here
allowed_origins	vec![] — Origin validation off	The browser-facing sibling of the DNS-rebinding defence we deliberately disabled via allowed_hosts. Inheriting it is harmless and consistent with the posture we chose, but that consistency is currently an accident of the default rather than a recorded decision.
stateless_protocol_metadata_required	false	Transport-level enforcement of the per-request _meta that the handshake-free lifecycle requires. Moot today — skips_the_handshake refuses that whole request class — but directly load-bearing for #34.

Why this is worth fixing rather than shrugging at

The section exists because inheriting a transport default "changes how a
deployment behaves without anyone choosing it". That rationale applies to the
whole config struct, not to the two fields that happened to be reviewed during
the rmcp 3.1 migration. An incomplete inventory presented as a complete one is
the failure mode this repo is otherwise careful about: it invites the next
reader to conclude the surface was audited when two fields were never looked at.

allowed_origins in particular deserves one sentence of recorded reasoning.
Today we disable allowed_hosts on the stated grounds that "its access control
is the network boundary and, when it lands, per-caller authentication (#32)".
That same argument covers Origin validation — but it should be stated to cover
it, so a future change to allowed_hosts does not leave allowed_origins
behind unconsidered.

Acceptance criteria

• The DESIGN.md inventory covers every StreamableHttpServerConfig field
  whose default is security- or limit-relevant, or says explicitly that it
  enumerates only the fields set by name and why the rest are inherited.
• allowed_origins carries a recorded decision (inherit, and the reason),
  not just an absence.
• stateless_protocol_metadata_required is named, with a pointer to Adopt the 2026-07-28 MCP revision — audit schema v1 assumes three things it removes #34 as
  the place its value gets decided.
• The count ("two") is replaced by something that cannot go stale silently
  on the next SDK bump.