Record SEP-1913 feedback as cited open questions; clarify untrusted vs openWorldHint

Enrich the base extension docs so the early review history is preserved rather
than erased by the narrow first cut:

- trust-annotations.mdx: add a normative subsection distinguishing result-level
  untrusted from tool-definition openWorldHint (the SEP-1913 #711 distinction).
- open-questions.md: capture the sensitivity-field shape debate, enforcement-vs-
  advisory risk, per-block byte ranges, taint persistence, and sequence-shape,
  each attributed to the reviewer who raised it; add a Naming (under review)
  section for the contested field/extension names.
- related-work.md: add verified FIDES alternatives (Permissive IFC 2410.03055,
  AirGapAgent 2405.05175, CaMeL 2503.18813) and a schemes-vs-host-architectures
  distinction.
- decisions.md: log the scheme/architecture boundary and the feedback-capture
  decision.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

docs/open-questions.md

@@ -16,13 +16,50 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
 
 ## trust-annotations
 
-- Is `sensitive` the right single coarse signal, or do we need the
-  `data-class.v1` profile from day one?
+- **Shape of the sensitivity signal.** Is `sensitive: boolean` the right single
+  coarse signal, or does the narrow cut overcorrect? The SEP-1913 thread rejected
+  a linear `sensitiveHint: low|medium|high` because sensitivity is set-theoretic,
+  not a scale ([@JustinCappos](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2967516811):
+  medical results to a mail MCP *and* a card number to a payment MCP, but neither
+  crossed). Reviewers then pushed for org-defined vocabularies
+  ([@olaservo](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2968743154),
+  [@Mossaka](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2971788308))
+  and a class+regulatory pairing such as `confidential:hipaa`
+  ([@krubenok](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#discussion_r3103485194)).
+  Against that, [@localden](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4037623595)
+  warned a baked-in taxonomy is hard to remove. Open: keep the boolean and let
+  the [`data-class.v1` scheme](../schemes/data-class.md) carry the taxonomy, or
+  also expose a structured escape hatch on the wire so regulated flows are
+  expressible without a scheme?
+- **Enforcement vs. advisory.** A self-declared `sensitive: true` from a
+  poorly-configured or malicious server could create a false sense of security
+  ([@localden](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4037623595)).
+  [docs/trust-model.md](./trust-model.md) puts verification in registries; is
+  that enough without a normative client-side check path?
 - Content-block-level vs. result-level attachment — does the draft need a
-  worked multi-result example before it's implementable?
+  worked multi-result example before it's implementable? Per-block annotation
+  with **byte/codepoint ranges** was requested so clients can highlight the
+  flagged span, not just the whole result
+  ([@connor4312](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-3849207989)).
 - `list_changed`: confirmed response-level annotations don't participate; revisit
   only if trust vocabulary ever attaches to tool definitions.
 
+## Naming (under review)
+
+These are explicitly unsettled and are being reviewed against the SEP-1913
+record before any rename lands:
+
+- **Umbrella name.** The original SEP was "Trust *& Sensitivity* Annotations" —
+  two axes (integrity *and* confidentiality). `trust-annotations` reads as the
+  integrity half; does the name hide the `sensitive` (confidentiality) half?
+- **`untrusted` vs `openWorldHint`.** Same concept, different layer (result vs.
+  tool definition). Share a name/vocabulary, or keep them deliberately distinct?
+- **`evidenceRef.type` vs `evidenceRef.scheme`.** The repo calls these values
+  "schemes" (`schemes/`); the selector field is `type`. Align the field name?
+- **`evidenceRef` itself.** Its ancestor is [@pshkv](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4196867926)'s
+  `decision_ref` / `attestation_ref` / `policy_profile`. Is `evidenceRef` the
+  clearest umbrella, or should the pointer name the kind of thing it references?
+
 ## action-metadata
 
 - Coexistence vs. replacement of legacy `destructiveHint` / `readOnlyHint` /
@@ -42,8 +79,20 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
 
 ## Parked (SEP-1913 umbrella)
 
-- **`maliciousActivityHint`** — if it returns, it is per-`ContentBlock` with
-  spans, driven by the host's own detection, not a server-attested boolean.
+- **`maliciousActivityHint`** — killed in review on three grounds
+  ([@connor4312](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-3849207989)):
+  it can't be resolved before execution for dynamic tools; a boolean gives no
+  UX or ranges; and clients won't trust a server's self-report of its own
+  maliciousness. If it returns, it is per-`ContentBlock` with spans, driven by
+  the **host's** own detection, not a server-attested boolean.
+- **Taint persistence across the store boundary** — a label must survive
+  round-tripping through storage: write a card number to a file, read it back,
+  and the sensitivity label must not silently disappear
+  ([@JustinCappos](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2967516811)).
+  This is a propagation property no single response annotation can guarantee on
+  its own; it needs the taxonomy and `evidenceRef` stable first.
 - **Session-level propagation rules** — escalation semantics and the
-  sequence-shape gap ("this was call N in a flagged sequence" has no response
-  annotation surface today).
+  **sequence-shape** gap: "this was call N in a flagged sequence" has no response
+  annotation surface today ([marras0914](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)).
+  A candidate `evidenceRef` scheme could carry a sequence assertion; tracked in
+  [`schemes/README.md`](../schemes/README.md).