feat(notations): ship core METRIC element type

[transitrix]

Summary

• Ships the core METRIC element type per the 2026-07-30 core-vocabulary decision: the managed indicator an organisation tracks to know whether a GOAL is moving, or whether a CAPABILITY / PROCESS is performing as intended.
• New notations/ELEMENT_PRIMITIVES.md §7.26: fields measures (non-empty list of GOAL-… / CAPABILITY-… / PROCESS-…) / unit / target / direction_of_good (higher_is_better | lower_is_better | on_target) / owner_role. No ArchiMate counterpart — stated explicitly per the 2026-07-30 vocabulary rule.
• New TYPE-registry row and uniqueness-scope row in notations/IDS_AND_REFERENCES.md §3.1 / §4; catalogue path 01_motivation/metrics/; validator rules METRIC-001..004 in ELEMENT_PRIMITIVES.md §9.
• Explicit disambiguation from COVERAGE_METRIC (a report-config document with no canonical content of its own, computing a regulatory dark-cell count) in both the element spec and the IDS registry entry — the two share a name root but are opposite kinds of thing.

Context worth flagging

• Worked example lives in the companion repo, not here: this repo carries no canon/ instance data of its own. Companion PR: feat: add METRIC worked example acme-corp#60 (METRIC-REVENUE-GROWTH-1.yaml + folder README).
• Checked COVERAGE_PROFILES.md and plugin.json (both named in the acceptance criteria): COVERAGE_PROFILES.md's full preset already covers "every TYPE in the registry" by reference — no edit needed. plugin.json has no per-TYPE registry (it lists views/reports, not element TYPEs) — nothing to update there either. Same conclusion as the sibling RISK change, noted there for the same reason.
• CHANGELOG.md intentionally left untouched — this is one of several sibling changes landing in parallel PRs against the same file; a single aggregating entry is better done once, after they all land.
• Placed METRIC in the motivation layer (01_motivation/metrics/), alongside ASSESSMENT — it's a measurement primitive over the organisation's intent, even though what it measures (GOAL / CAPABILITY / PROCESS) can sit in a different layer. Rationale spelled out in the new §4.1 bullet.

Test plan

• node scripts/check-notations.mjs → clean
• npx @transitrix/cli validate --scope=repo --json → valid: true
• Re-read tails of both edited files — no truncation
• Companion acme-corp fixture validated (--scope=repo --json → valid: true; per-file CLI validation correctly reports the notation isn't registered yet — expected, Studio follow-on is separately filed)