* Restructure draft transport documentation

The transports page presented MRTR, subscription streams, and the
request-metadata model as Streamable HTTP features, while the stdio
section was silent about them. The split mirrored the old transport
model, where each transport had genuinely different capabilities. In the
current draft, protocol semantics are identical on every transport; only
the binding differs.

- Split basic/transports.mdx into a transports/ section:
  - index.mdx: transport-independent overview — the client-initiated
    message flow, MRTR and subscriptions/listen as the only
    server-to-client mechanisms on any transport, the per-request
    metadata model, and what a binding must define.
  - stdio.mdx and streamable-http.mdx: per-transport bindings.
- Move MRTR from basic/utilities/ to basic/transports/, since it is part
  of the transport message flow rather than an optional utility. Add a
  redirect for the old URL.
- Remove leftovers from the bidirectional era: clients no longer send
  JSON-RPC responses on either transport, and the stdio page now states
  explicitly that servers must not write JSON-RPC requests to stdout.
- Update navigation and all draft-internal links.

* Fix typos in MRTR security requirements

* Note that stdio framing generalizes to any byte stream

The stdio wire format (newline-delimited JSON-RPC over a reliable
bidirectional byte stream) is not specific to standard streams; only the
process-lifecycle rules are. State this on the stdio page and recommend
that custom stream-based transports (Unix domain sockets, TCP) reuse the
stdio framing instead of defining new framing.

* State the transport message flow declaratively

* Trim request metadata wording in transport overview

* Replace em-dashes with plain punctuation in new spec text

* Make message-direction rules prescriptive in transport bindings

* Clarify stdio receiving-messages section

* Deduplicate backward-compatibility text across lifecycle and transports

The era-detection mechanics were spelled out three times: in lifecycle,
in the transport binding pages, and partially in server/discover. The
copies had already drifted once.

- Binding pages are now canonical for detection mechanics. The stdio
  page absorbs the detail previously only in lifecycle (preferred
  version in _meta, three probe outcomes, supportedVersions selection).
- Lifecycle keeps the transport-independent content: the era model,
  caching guidance, and the compatibility matrix. It links to the
  binding pages for mechanics.
- server/discover refers to the stdio binding page instead of restating
  the fallback rules.

* Reorder lifecycle page: scope first, transition material last

- Open with a scope statement and a short overview instead of normative
  rules.
- Add a terminology section defining modern, legacy, and dual-era before
  first use (previously defined inside the compatibility-matrix intro).
- Group the statelessness requirements under their own heading; split
  compound bullets and demote the connection-identity rationale to a
  note.
- Move extension negotiation before backward compatibility, so core
  protocol material precedes transition material.
- Promote backward compatibility to a top-level section (anchor
  unchanged).

* Reorder transport overview: scope first, transition material last

- Open with a scope statement instead of the UTF-8 encoding rule; the
  encoding requirement moves to the top of Message Flow.
- Move Custom Transports before Backward Compatibility, so requirements
  for new bindings precede transition material.

* Add message patterns page; keep MRTR under utilities

Review feedback on the transport restructure: MRTR describes message
flow and contents, like subscriptions and progress, which live under
utilities. Moving only MRTR under transports was inconsistent. The
underlying gap is that no page defined the core message patterns every
transport carries.

- Add basic/patterns.mdx (Message Patterns), after Lifecycle in the nav.
  It defines the client-initiated model and the three core patterns
  (request/response, multi round-trip requests, subscribe and notify),
  each with a sequence diagram and a link to its detailed page, and
  states that new patterns are added there without transport changes.
- Move MRTR back to basic/utilities/ and drop the redirect.
- Slim the transports overview to binding concerns: message delivery
  requirements, metadata carriage, cancellation, custom transports, and
  backward compatibility. It links to the patterns page for flow
  semantics.

* update basic/index.mdx to reference message patterns page

* add message patterns

* Align pattern names between overview and patterns page

Use the same pattern names and order in the base-protocol overview as on
the patterns page, and link each pattern to its section. Rename the
Request/Response heading to Request and Response so its anchor does not
contain an encoded slash.

* Title the transports index page Overview, matching other group index pages

* Rename Lifecycle to Versioning and Compatibility

The protocol is stateless: there is no initialize/operate/shutdown
sequence left to describe. Initialization became per-request metadata,
and shutdown is a transport-binding concern documented on the binding
pages. The remaining content of the lifecycle page has one theme: how
two implementations agree on what they are speaking.

- Rename basic/lifecycle.mdx to basic/versioning.mdx, titled
  "Versioning and Compatibility", covering version negotiation,
  extension negotiation, and backward compatibility. Add a redirect.
- Move the statelessness section to the base-protocol overview, where
  the execution model belongs.
- Update navigation and all draft-internal links.

---------

Co-authored-by: Caitie McCaffrey <caitiem20@github.com>