Gate GET /subject-labels by per-page read permission

[alistair3149]

Fixes #1060

What

GET /neowiki/v0/subject-labels (the Subject autocomplete) returned the labels of Subjects on
pages the caller cannot read, and accepted an uncapped limit. This gates it by per-page read
permission and bounds the work, mirroring the read-gate work from #1058 / PR #1058.

Fixes the leak described in #1060.

Changes

• Read gate. The Cypher now traverses (:Page)-[:HasSubject]->(:Subject) so the owning page id
  reaches PHP, and each row is dropped unless PageReadAuthorizer::authorizeReadByPageId allows it —
  the same authorizeRead('read', $title) binding check the other read endpoints use. Denied
  Subjects are simply absent (never a 403), so restricted pages cannot be enumerated. This
  mirrors DatabaseSchemaNameLookup::filterReadable.
• limit cap. PARAM_MAX => 50 (and PARAM_MIN => 1), matching GET /layouts. Without it a
  per-result permission check was an unbounded-work vector (?limit=100000 was accepted).
• Over-fetch, bounded. The query over-fetches (limit × 4), then rows are authorized one at a
  time and collection stops at limit, so read restrictions tend not to shorten the result while
  the expensive per-page check runs only for the rows actually needed, not the whole over-fetched
  window.
• Wiki scoping on both ends. The traversed page is scoped to the current wiki
  ((:Page { wiki_id })) in addition to the existing subject scope (n.wiki_id). The page scope
  keeps the returned page id resolvable within this wiki (page ids are unique only per wiki, so a
  foreign page id would gate an unrelated local page); the subject scope keeps 5d802e6's ownership
  guarantee. Both are independently mutation-verified below.

Testing

• Neo4jSubjectLabelLookupTest (14): adds a denial test, an over-fetch/re-limit test, and two
  wiki-scope tests (a foreign subject on a local page; a local subject also referenced by a foreign
  page). The two pre-existing cross-wiki isolation tests were made non-vacuous — their fixtures now
  create a Page + HasSubject edge so exclusion is attributable to the wiki filter, not to a
  missing page.
• Mutation-verified load-bearing: removing n.wiki_id fails exactly
  testExcludesForeignSubjectsReachableThroughALocalPage; removing the page { wiki_id } scope
  fails exactly testReturnsALocallyOwnedSubjectOnceWhenAForeignPageAlsoReferencesIt.
• GetSubjectLabelsApiTest (new): ?limit=100000 → 400.
• NoGraphBackendTest, RestApiDocsCoverageTest, ModuleSpecHandlerNeoWikiTest,
  DocsPathReferencesTest green; make cs (phpcs + phpstan) clean.
• The frontend caller (RestSubjectLabelSearch.ts) sends no limit, so PARAM_MIN/PARAM_MAX
  cannot break it; no frontend change.

Smoke tested on a live wiki

Verified end-to-end on the dev wiki (/w/rest.php), beyond the automated suite:

• limit cap: ?limit=100000 and ?limit=51 → 400 ("must be between 1 and 50"); ?limit=50 → 200; ?limit=0 → 400; missing schema → 400.
• Read gate: with anonymous read of the Acme Rocket page denied via a getUserPermissionsErrors hook, GET /neowiki/v0/subject-labels?schema=Product&search=a dropped that Subject's label — [Acme Anvil, Acme Rocket, Acme TNT] → [Acme Anvil, Acme TNT] — while other Subjects and other schemas were unaffected; lifting the restriction restored it. Denied Subjects are absent, identical to a Subject that does not exist.

_{AI-authored — Claude Code, Opus 4.8 (1M context); asked to implement #1060 by @alistair3149, with mid-run direction to re-review and smoke-test; diff not yet human-reviewed; TDD (tests seen failing before the fix) with both wiki-scope clauses mutation-checked, independently AI-reviewed (a 4-lens adversarial workflow then a fresh read-only code review, findings applied), targeted PHPUnit filters (lookup, API, wiring, doc-coverage) + phpcs + phpstan green locally, live-smoke-tested on the dev wiki (limit cap + read-gate omission), CI pending.}