docs: ADR 0008 — peer-extension boundary (datasets first)

[DecisionNerd]

Native sub-issue of #20 in M14: Peer Extensions for v0.5.x.

Goal

Author docs/adr/0008-peer-extensions.md recording the decision that GraphForge extensions
(datasets first; later ontology / algorithm / epistemology / UI) are peer crates over the public
gf-api SDK, and that Core never depends on an extension.

Content

• Context: datasets are greenfield (old registry lived only in the deleted Python shim, CurateLabs/graphforge-legecy#862);
  ADR 0006 already forbids lower→higher layer deps. This ADR names the concrete extension point.
• Decision: peer extensions are crates depending on gf-api, never on gf-core/graph layer;
  they ship their own language packages; Core stays extension-agnostic.
• Enforcement: a CI delete/boundary gate (workspace builds with the extension removed; no
  graph-layer crate depends on it).
• Consequences (pos/neg) and Alternatives considered (language-packages-only; separate repo).

Match the house style of ADR 0006/0007 (frontmatter: Status / Date / Build target / Related).

Done when

• docs/adr/0008-peer-extensions.md merged
• Referenced from the epic (feat(io): interchange exact ontology composition closures #877) and ADR 0006