repo: make trust-annotations the base; FIDES becomes a scheme, not a sibling

Restructure the incubation into two extensions plus interchangeable data-labelling
schemes, shipped as a stack of three PRs:

- This PR (base): shared scaffolding + the trust-annotations extension.
- action-metadata moves to its own stacked PR.
- The IFC/FIDES work moves out of specification/draft/ entirely — it is one
  data-labelling scheme (ifc.fides.v1) that fills the trust-annotations
  evidenceRef slot, not an extension and not a sibling. It lands in a schemes/
  folder built to hold alternative approaches (data-class, capability tokens,
  cosigning, sequence-shape, attestation) so no single academic model is baked
  into the wire.

README, sep-disposition, related-work, trust-model, open-questions and the
decision log are reframed accordingly (two extensions + a schemes folder; the
range of candidate schemes drawn from the SEP-1913 thread and cited literature).

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

docs/open-questions.md

@@ -30,7 +30,7 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
 - Open strings vs. closed enums for `destination` / `source` / `sensitivity`.
 - Does `requiresReview` need a machine-readable *reason* for good client UX?
 
-## ifc-fides
+## ifc-fides (scheme)
 
 - Inline `_meta.ifc` for low-friction adoption vs. always behind `evidenceRef`.
 - GitHub Enterprise `internal` repo visibility → `public`/`private` mapping