fix: widen KNOWN_RELS to cover all four sibling plugins' typed relations

[RichardHightower]

What this is

scripts/okf-graph.py's KNOWN_RELS allow-list controls which edge relation names validate treats as normal vs. flags with a non-standard rel (allowed but uncommon) info line. It started this PR at 11 entries; the first commit widened it to 37 by adding okf-agent-graph's (AGER — OKF Agent Graph Engineering Runtime, the plugin that models multi-agent loop config) vocabulary. That stopped short arbitrarily.

This update widens it the rest of the way. OKF (Open Knowledge Format) has four sibling "capture" plugins that write typed edges into knowledge bundles, each declaring its own relation vocabulary on top of OKF's 11 core relations:

• okf-agent-graph (AGER) — 26 relations beyond core (already covered by commit 1)
• project-knowledge-capture (PKC) — 15 relations beyond core (decisions, requirements, features, experiments)
• system-architecture-capture (SAC) — 84 relations beyond core (services, APIs, infra, C4 diagrams, data flow)
• data-engineering-knowledge-capture (DEKC) — 38 relations beyond core (tables, pipelines, lineage, BI)

None of PKC/SAC/DEKC's relations were in KNOWN_RELS, so any bundle built with those plugins had every one of its typed edges flagged as "non-standard" — noise that makes filtering validate output a habit, which is exactly how a real typo gets missed.

The fix

KNOWN_RELS is now CORE_RELS | AGER_RELS | PKC_RELS | SAC_RELS | DEKC_RELS — 161 relations total (up from 37), restructured into five named, source-cited frozensets instead of one flat literal, so provenance stays readable and a future plugin release is a one-set diff:

CORE_RELS   = frozenset({...})   # the original 11
AGER_RELS   = frozenset({...})   # okf-agent-graph 0.5.0, docs/AGER_SPEC.md
PKC_RELS    = frozenset({...})   # project-knowledge-capture 0.6.0, docs/typed-edges.md
SAC_RELS    = frozenset({...})   # system-architecture-capture 0.3.0, schemas/types.json
DEKC_RELS   = frozenset({...})   # data-engineering-knowledge-capture 0.2.0, doc + code union
KNOWN_RELS  = CORE_RELS | AGER_RELS | PKC_RELS | SAC_RELS | DEKC_RELS

Each plugin's vocabulary was derived from its own newest-installed docs (docs/typed-edges.md), then cross-checked against its own enforced code (each plugin's DEFAULT_RELATIONS Python constant, the list its own capture/link tooling actually validates against) to catch doc drift rather than trust the prose blindly:

• PKC: doc and code agree exactly (15 relations). No discrepancy.
• SAC: its docs/typed-edges.md undercounts by 12 relations — it's missing the entire C4 model vocabulary (c4_contains, c4_delivers, c4_implements, c4_uses, c4_view_of, zooms_into, documented instead in a separate docs/c4-integration.md) and 6 code-structure relations (defines, has_field, invokes, owns_capability, source_of, syncs_with). Used schemas/types.json's relations.sac bucket instead — the structured registry sac_validate.py itself loads at runtime — which is a strict superset of both the doc and the code constant (84 relations).
• DEKC: doc and code disagree in both directions — the doc has 4 relations (documented_by, has_wireframe, validated_by, wireframes) the code's DEFAULT_RELATIONS doesn't, and the code has 4 (aggregates, computes, documents_diagram, joins) the doc doesn't. Used the union of both (38 relations) rather than silently picking one, since widening KNOWN_RELS is safe either way (see below).

Why widening is safe

Confirmed both use sites of KNOWN_RELS in scripts/okf-graph.py:

1. extract_frontmatter_links (~line 484): rel = (item.get("rel") or item.get("type") or "related_to").strip() already guarantees rel is non-empty before the KNOWN_RELS check runs. if rel not in KNOWN_RELS: rel = rel or "related_to" is a no-op for any non-empty rel regardless of KNOWN_RELS membership — rel or "related_to" evaluates to rel itself when rel is truthy. Widening KNOWN_RELS cannot change the edge's rel value here, before or after this change.
2. validate() (~line 1068): if e.source == "frontmatter" and e.rel not in KNOWN_RELS and e.rel != "links_to": issues.append(info "non-standard rel"...). This is the only place KNOWN_RELS membership changes behavior — widening it only removes info-severity messages for now-recognized relations. It does not affect error/warn issues (the broken link error check is keyed on e.target, not e.rel) and cannot change which edges get built.

Drift-guard test rewrite

The old test_known_rels_covers_ager_vocabulary compared a hardcoded literal to KNOWN_RELS — close to tautological. Added test_known_rels_covers_sibling_plugin_vocabularies, which:

• When PKC/SAC/DEKC are installed locally, parses their live vocabulary sources at test time (docs/typed-edges.md, each plugin's DEFAULT_RELATIONS constant, and SAC's schemas/types.json) and asserts every relation they declare is in KNOWN_RELS — a genuine check that fires the moment a plugin adds a relation this file hasn't caught up with.
• When they aren't installed (CI), falls back to asserting the five embedded frozensets are each a subset of KNOWN_RELS.

Proved the guard actually catches drift: temporarily removed c4_uses from SAC_RELS, re-ran the suite — it failed with:

FAIL test_known_rels_covers_sibling_plugin_vocabularies: KNOWN_RELS is missing SAC 0.3.0 relations declared in
.../sac-plugin-marketplace/system-architecture-capture/0.3.0: ['c4_uses']

— then restored it and confirmed the suite is green again.

Before / after (real bundles — field-ops-knowledge-base)

Bundle	Before this PR (11 core relations)	After AGER commit (37)	After this update (161)
knowledge/	8 non-standard rel info lines	8 (unchanged — all PKC relations, e.g. originates_from)	0
agent-graph/	14 non-standard rel info lines	0 (fixed by the AGER commit)	0

Version

Stays at 0.4.1 (unreleased) — this PR hasn't merged yet, so the AGER commit's version bump covers this update too. Version-consistency test still passes.

Verification

• python3 tests/test_okf_graph.py — 31/31 green (was 30)
• bash tests/test_okf_curate.sh — green
• python3 scripts/okf-graph.py validate sample-okf --strict — 0 errors, 0 warnings

Closes #51