The x-mcp-header extraction rule was undefined for properties nested
under array 'items', inside composition or conditional keywords
(oneOf/anyOf/allOf/not, if/then/else), or behind $ref: such properties
have no single static location in the call arguments.

- x-mcp-header annotations are now only valid on properties reachable
  from the schema root via a chain consisting solely of 'properties'
  keys. Annotations anywhere else make the tool definition invalid,
  triggering the existing client rejection rules.
- Define extraction as reading the instance value at the annotated
  property's exact path; if the value is absent, the header is omitted.
- Mirror the rule in the Tool.inputSchema schema documentation.

notifications/elicitation/complete had no legal delivery channel: the
HTTP GET stream is gone, response-stream notifications must relate to
the in-flight request, and the subscriptions/listen filter had no field
covering elicitation completion — while servers must not send
notification types the client has not requested.

- Add an opt-in elicitationComplete boolean to SubscriptionFilter;
  when true, the server may deliver notifications/elicitation/complete
  on that subscription's stream.
- Document on ElicitationCompleteNotification that it is only sent to
  clients that opted in via elicitationComplete and is delivered on
  that subscription's stream (with the subscription ID in _meta).
- Document the URL-mode elicitation flow: the client subscribes via
  subscriptions/listen with elicitationComplete: true, waits for the
  completion notification, then retries the original request.
- Regenerate schema.json and the schema reference.

With the multi round-trip request pattern, clients learn the outcome of an
out-of-band URL mode elicitation by retrying the original request, so a
server-initiated completion signal no longer has a place in the flow.

- Drop ElicitationCompleteNotification and its params from the draft schema
- Drop the elicitationComplete subscription filter field
- Remove the completion notifications section from the elicitation page and
  update the URL mode flow diagram
- Note the removal in the draft changelog

The completion notification was the only consumer of this identifier. With
notifications/elicitation/complete gone, servers correlate an elicitation
across retries via requestState instead, so the field has no remaining
protocol-level purpose.

The full reachability and extraction rules live in the Streamable HTTP
transport spec; tools.mdx and the Tool schema comment now reference them
instead of restating them. Also remove the protocol-version section's note
about notification POSTs: the core protocol defines no client-to-server
notifications over Streamable HTTP, so nobody will look for that answer
there, and the Sending Messages note already covers it.