Widen SubjectId to a source-qualified pair

[malberts]

For #993 (work order T1).

SubjectId (PHP and TS) is now a (source, localId) pair per the Identity section of
ADR 23:
the bare nanoid form stays valid everywhere and means the local source, and a qualified
source:localId form can be carried across every boundary. This is a type-and-wire-format change
only: nothing can be done with a sourced id yet, no path creates sourced Subjects, and local
Subjects stay stored bare (slot JSON, Neo4j id properties, and API output unchanged, per ADR 22).

Owner design calls made in this PR, within the ADR's boundaries:

• Serialized form: source:localId, splitting on the first : only, so future URI-shaped
  localIds stay expressible. : is absent from both the nanoid alphabet and the key grammar, so
  the two forms cannot collide.
• Source-key grammar: [A-Za-z0-9+_-]+, compared case-sensitively. The authority for what a
  wiki's key can look like is the installer, not WikiMap (which concatenates verbatim): MySQL
  dbnames validate as /^[a-z0-9+_-]+$/i and SQLite dbnames are unchecked. Case-sensitivity is
  load-bearing rather than style: with lower_case_table_names=0 (the MySQL/MariaDB default on
  Linux) two dbnames differing only in case are distinct databases, so two wikis' keys can differ
  only in case too, and the graph's wiki_id property stores the wiki ID verbatim, which
  forecloses case-folding. Because hand-set dbnames are unconstrained, a configured local key
  outside the grammar never throws; it is compared verbatim, and such keys simply cannot appear in
  qualified input strings.
• Canonicalization: an id that explicitly names the local source normalizes to bare at parse
  time, so one Subject never has two textual identities (equals() and the text-keyed collections
  stay sound). Parsing happens in the new SubjectIdParser (PHP and TS), constructed with the
  local source key (WikiMap::getCurrentWikiId() server-side, wgWikiID client-side, which is
  the same value by construction) and threaded to the boundary parse sites from the composition
  root. Ids read back from the local graph keep the plain constructor, being canonical by
  construction.
• Interim localId rule (until T2 delegates grammar to Sources): non-empty and restricted to
  URL-path-segment-safe characters (RFC 3986 pchar minus percent-encoding). Looser rules cannot
  round-trip: MediaWiki REST rawurldecodes path parameters after routing, so for example %2F
  would reach the handler as /. RestSubjectRepository now also percent-encodes ids in URLs,
  as the schema and layout repositories already do (a byte-for-byte no-op for bare ids).
• Placeholder hydration: {{#view:}} injects arbitrary wikitext strings into the placeholder
  attribute, and the subject store is keyed by canonical id text, so hydration now parses ids
  instead of constructing them raw: an explicitly-local-qualified id resolves to the same store
  key as its bare form, and invalid input keeps degrading to a skipped view. The hydration logic
  moved to components/viewData.ts to be testable.

PHP/TS grammar parity is asserted rather than assumed: both suites consume the shared vector
fixture tests/subject-id-vectors.json (a new convention, per the work-order checklist item).
Object-level semantics stay in explicit per-language tests, and
testLocalOnlyPageSlotJsonRoundTripsByteIdentically pins that a local-only page's slot JSON
serialization is byte-identical through the new parse path.

Result of extensive back and forth with @malberts, building on the T1 work order.
Context: the NeoWiki codebase, ADRs 14/22/23 and the SubjectSources planning doc, the MediaWiki
core checkout (REST router, installer, ResourceLoader), and an adversarial multi-agent review of
the implementation plan.
_{Written by Claude Code, Fable 5 (max)}