Validate relation statement targets server-side

[JeroenDeDauw]

Fixes #1078

RelationType::validate() only emitted required and RelationProperty::getTargetSchema() had no
consumers, so relation statements went unchecked on write. An API write accepted a relation that
points at a Subject that does not exist, at a Subject whose Schema is not the property's
targetSchema, or that holds multiple targets on a multiple: false property. The subject editor's
picker hides this, but API-driven import does not go through the picker.

This adds three validations, using the severity model of ADR 26 as actually implemented (blocking vs.
Violation::NON_BLOCKING_CODES):

• single-value-only (error) for a multiple: false relation holding more than one target, emitted
  by RelationType::validate() exactly as SelectType does — no lookups needed.
• relation-target-schema-mismatch (error, new) when the target Subject exists but its own Schema
  is not the property's targetSchema.
• relation-target-not-found (warning, new, non-blocking) when the target id does not resolve.
  Deliberately non-blocking: pointing at a not-yet-created Subject is wiki-native red-link behaviour,
  and an import may mint the target later.

The last two live in SubjectValidator (the placement PR #1043 uses), since they need a lookup and
the writer's-schema RelationProperty, which PropertyType::validate() cannot reach. Targets are
resolved through the canonical revision-slot-backed SubjectLookup the read path uses
(getSubjectRepository()), never the secondary Neo4j projection; the target's Schema comes from its
own stored Subject. A missing target short-circuits, so it never also reports a schema mismatch.

Enforcement is unchanged: relation-target-not-found joins Violation::NON_BLOCKING_CODES (the
warning tier as implemented), and the newly-introduced-blocking-violation gate is untouched.

RelationInput already renders server violations generically via neowiki-field-<code> messages, so
the two new codes get i18n/en.json, i18n/qqq.json, and extension.json entries and no new UI
code. docs/api/validation-codes.md documents both codes and notes RelationType as a
single-value-only emitter.

ADR 26 (Draft) is intentionally not edited: its per-Constraint severity model is not fully
implemented, and PR #1043 set the precedent of not treating it as a living code catalog. Folding
these two fixed-severity system codes (mismatch = fixed error, not-found = fixed warning) into
ADR 26 is a follow-up for whoever finalizes it.

A textual conflict with open PR #1043 (which also touches SubjectValidator, the same three test
files, validation-codes.md, and the i18n / extension.json message list) is expected.

_{AI-authored — Claude Code, Opus 4.8 (max); batch execution of the Relations Phase 1 plan directed by @JeroenDeDauw, from a fixed spec with no redirection; not yet human-reviewed; TDD (red then green), full PHPUnit suite (1801 tests) + make cs (phpcs + phpstan) green locally, psalm clean on changed files, production-revert test-verification done; CI green (PHPCS, PHPStan, PHPUnit).}

Review notes (batch pr-review pass)

A fresh-session review pass fixed a blocking enforcement gap (relation-target violations now carry valuePartIndex, 122712b) and verified all three validations end to end (unit + mutation battery + live endpoint). Two architecture-level follow-ups were identified and deliberately left out of this PR pending a decision:

• The validate path resolves relation targets without page-read authorization, so violation responses can disclose whether an unreadable target exists and what its schema is (the read path gates exactly this per Enforce per-page read permission on Subject, Layout, and RDF read endpoints #1046). Likely fix: thread the read authorizer into target resolution and collapse unreadable targets into relation-target-not-found.
• Target resolution adds one live lookup per relation target on an anonymous, unrate-limited validate endpoint (no relation cap, no id dedup). Consider a cap, dedup/batching, or a ping limiter before ACL/farm deployments.

_{Review-pass notes added by Claude Code, Fable 5 (max), summarizing a fresh-session Opus 4.8 review agent's verified findings; not yet human-reviewed.}

[JeroenDeDauw]

@alistair3149 does this belong in the docs? Looks like we're now explaining a bunch of implementation details.

[alistair3149]

We can simplify it to A a target that exists in revision slots but is missing from the graph is reported as not found. It is a confusing behavior that should be documented. That will likely be solved with #1040.

[JeroenDeDauw]

I'm currently in a fierce debate with fable about this text. Its first take is to say the PR is good.

[JeroenDeDauw]

Ok this took some doing but it now agrees, FWIW

[JeroenDeDauw]

Deslop:

• Rewrite validation-codes.md at the API-consumer altitude #1106