Add per-subject RDF export endpoint

[JeroenDeDauw]

Fixes #1087

Adds GET /neowiki/v0/subject/{subjectId}/rdf, serving one Subject's outbound
bounded description as RDF: exactly the triples the page export emits for that
Subject, including the native relation reification, with none of the page-metadata
triples, in the hosting page's per-projection named graph. It mirrors the page
endpoint's format (trig/turtle) and projection (native/EDM/...) parameters and
their negotiation.

Mechanism:

• PageProjector gains projectSubject( Page, SubjectId ): QuadList, implemented by
  both the native and ontology-mapping projectors by reusing their existing
  per-Subject internals (the former private projectSubject helpers, renamed to
  subjectQuads). An absent Subject, or one whose projection yields nothing (native:
  Schema unavailable; ontology: the Subject's Schema has no entry in the target's
  Mapping page), yields an empty list — a readable Subject that projects to zero quads
  is a 200 empty graph, never a 404.
• RdfSubjectExporter resolves the Subject to its hosting page via the Neo4j
  PageIdentifiersLookup (the same dependency the subject JSON endpoint already
  carries), authorizes the page, loads it, and confirms the Subject is still in the
  current revision before projecting. A Subject that is unknown, has no readable or
  loadable hosting page, or is gone from the slot all return one byte-identical 404
  (anti-oracle parity, cf. Enforce per-page read permission on Subject, Layout, and RDF read endpoints #1046).
• ExportSubjectRdfApi validates the Subject ID shape first (400 on malformed, never
  a 500) and rejects an unknown projection (400) — read-filtering the listed projection
  names by the caller's permission — before resolving the Subject, so neither can be
  used to probe for restricted Subjects.
• The format negotiation shared with the page endpoint moves into a new
  RdfFormatNegotiation trait, keeping the two endpoints byte-for-byte consistent.

Docs: the rest-api.md endpoint table and the rdf-export.md endpoint section.

Integrates master's #1086 (one Mapping page per ontology): the per-subject projection
is re-fitted onto the single-page Mapping model (Mapping::forSchema()), the handler
adopts filterReadableProjectionNames(), and projection names are now case-sensitive
Mapping page titles (e.g. EDM).

_{AI-authored — Claude Code, Opus 4.8 (max); detailed spec from a triage session (@JeroenDeDauw), built end-to-end with no mid-task human steering, then integrated a conflicting master merge (#1086); not yet human-reviewed; TDD unit + integration tests with a mutation pass (every mutation caught), touched PHPUnit suites + phpcs/phpstan green locally, live-verified against the dev wiki after the merge (native, TriG named graph, EDM via the new single-page mapping, and 404/400 paths), CI green post-merge; final docs-wording tweak by the reviewing session (Fable 5 (max)).}

In-session AI review

Reviewed in-session (pre-merge) by three independent read-only agents (correctness, security, design-optimality). No blocking findings: the anti-oracle 404 byte-parity and the hosting-page read gate were verified, and the design verdict was optimal (every element of structure warranted; the two rejected simpler alternatives — whole-page-projection-then-filter, and a fake single-subject Page — were verified to genuinely fail the goal). Two minor findings were applied: an integration test for the readable-but-unmapped-Subject 200 empty-graph contract, and a docstring/doc clarification. The subsequent #1086 merge re-fit preserves these; no human has reviewed the diff.

[JeroenDeDauw]

[JeroenDeDauw]

@malberts can you deploy this to demo wiki?

@malberts @alistair3149 Thoughts on UI enhancements? Follow-ups welcome.

Doing some expedited merging here since getting this live on the demo wiki allows for feedback, and it's part of the entire RDF/Ontology/QLever flow which I've self-merged and is known not-fully-reviewed yet and very much a best-guess spike.