Add FIDES as a data-labelling scheme under schemes/

[SamMorrowDrums]

FIDES as a data-labelling scheme (not an extension)

This is the third PR in the SEP-1913 split. It adds FIDES as one
data-labelling scheme under a new schemes/ folder, rather than as an
extension or a sibling of the two extensions.

• schemes/ifc-fides.md — the FIDES information-flow-control label
  (integrity × confidentiality), selected by evidenceRef.type == "ifc.fides.v1" on a trust-annotations annotation. A client that does not
  implement IFC ignores it safely.
• schemes/README.md — the index for the folder: what a scheme is, FIDES as the
  worked example, and the range of candidate schemes raised in SEP-1913 review
  (data classification, design-pattern controls, ShardGuard, capability tokens,
  cosigning, sequence-shape, attestation), plus the bar a scheme doc must meet.

Why a scheme, not an extension

Information-flow control is one enforcement model among several. Making it an
extension (io.modelcontextprotocol/ifc) would put the FIDES lattice at the
namespace root and foreclose the other models. As a type value behind the open
evidenceRef slot, FIDES is first-class while the slot stays free for the rest.
The schemes/ folder exists to hold those interchangeable approaches.

Stack

Stacked on sammorrowdrums/extensions-scaffold-trust-ifc-action (the base / PR
that adds the scaffolding + trust-annotations). FIDES fills that extension's
evidenceRef slot, so it depends on the base. Merge order: base → this.
Retarget to main once the base merges.

Review continuity

The normative body here is the same text reviewed by @JoannaaKL and @Rul1an on
the original combined PR (their threads are now marked outdated there because the
file moved out of specification/draft/). Their changes are preserved verbatim:
public/private-only confidentiality, the wire-hint vs host-resolved split,
the integrity-total / confidentiality-partial asymmetry, fail-closed on
unresolvable reader sets, and the no-durable-grant rule.

Note: commits in this stack are currently unsigned due to a local signing
agent issue; they can be re-signed on request before merge.

[Rul1an]

The scheme-versus-extension split lands it right: keeping the models behind evidenceRef.type rather than at the namespace root is what preserves the open-type intent, and schemes/ gives the interchangeable approaches a home without any one claiming the wire.

Bar point 4 (a candidate emitter and consumer, validated not asserted) is the load-bearing one, and #5 already supplies it for two of the candidate rows: data-class.v1 covers the public-repo-with-private-subresource classification, and sequence covers re-derivation from the record bytes, both reproducible from examples.json alone under cbor/rfc8949 and jcs/rfc8785. Happy to align their type strings and move them next to schemes/ once the registry settles.

One distinction worth pinning early: #5's policy-decision (a decision record) is close to but not the same as the "tool-call attestation (in-toto / OVERT)" candidate from SEP-2787 (a signed statement about a call). Probably worth deciding whether those are one scheme or two before the type values settle.