Let approval extensions choose the revision NeoWiki publishes

[alistair3149]

Fixes #1379

NeoWiki published each page's latest revision everywhere except the page view, so an approval extension such as
ContentStabilization could stabilize what a reader sees on a page but not what the graph stores or the RDF export
served. It already registers a Page Property Provider with us and calls newPageRebuilder()->rebuild() when a
stable point changes; it had no way to say which revision that rebuild should read.

Extensions can now register a RevisionPolicy through NeoWikiRegistrar::setRevisionPolicy(). It answers three
questions, each asked where it is natural:

• publishesRevision() — asked as a revision is written. A save already has its revision and only needs to know
  whether to publish it, so this costs one lookup. Return false and the graph keeps whatever it published before.
• publishedRevision() — asked when nothing but the page is known: by PageRebuilder::rebuild(), the reprojection
  path an approval extension calls when its answer changes, and on every Schema, Layout, Mapping and configuration
  read and every RDF export. Returns the revision to publish, or null when the page has nothing publishable.
  rebuildFromPrimary() deliberately does not ask: import and undelete write a revision, so they take the save
  path's semantics.
• revisionIsReadableBy() — asked when a caller names a revision by id, which neither publishing method can
  intercept. A refused revision answers exactly like an absent one, so the sequential revision ids stay unsweepable
  (Enforce per-page read permission on Subject, Layout, and RDF read endpoints #1046).

Registration is a single slot rather than the add* list every other extension point uses, because two extensions
cannot both decide this. A second policy is refused with a warning and the first keeps deciding. With nothing registered every surface reads the latest revision, exactly as before.

The registered policy is wrapped in FailureIsolatingRevisionPolicy, as every other extension-contributed plugin is.
A policy that throws publishes nothing and hides everything — the edit hook fires inside PageUpdater's atomic
section, so an uncaught throw there would roll the contributor's save back. It also refuses a revision from another
page, and a revision whose text is suppressed: only the current revision was ever projected before, and core forbids
suppressing that one, so a policy naming an older revision must not start publishing suppressed Subjects.

The subject-to-page index is deliberately not governed by the policy

It records where a Subject lives, not whether it is published, and it is written from every revision. Every id-keyed
read and write addresses its page through it — ReplaceSubjectAction, UpdateStatementAction, DeleteSubjectAction,
MoveSubjectAction, and the check in CreateSubjectAction that an id is not already taken — so a Subject left out of
it could not be edited, moved or deleted, and its id would read as free and be re-mintable onto another page. Adding a
Subject in an unapproved revision is the normal case on an approval wiki, so that would fire constantly.

Keeping the index out of it also makes the maintenance rebuilder correct rather than contradictory: it writes from
page_latest and needs no knowledge of the policy, which is why it can keep running under update.php.

Which surfaces this covers

The graph projection and the RDF export publish through the policy. Schemas, Layouts, Mappings and the on-wiki
configuration page read through it too, so an unapproved edit to one does not take effect until it is approved; the
Schema editor is unaffected because it loads page source through core's own /v1/page/ endpoint.

Reads by Subject id stay on the latest revision. Routing them through the policy is what an earlier revision of this
branch did, and it broke the subject editor: the same endpoint is the editor's load path, so the editor loaded
approved values and saved them back over the draft.

Known gaps, all tracked

• Three Subject read surfaces still serve the latest revision — action=subjects, the page-keyed REST read, and
  referenced Subjects on other pages via PointInTimeSubjectLookup
  (Subject read surfaces serve the latest revision, not the published one #1390). The parse-time accessors are unchanged for a different
  reason: they need the parser's own current-revision callback rather than this interface.
• The RDF export stops answering for a page once approval is withdrawn, but what was published stays in the graph
  until the page is deleted; a rebuild does not remove it (Revoking approval does not withdraw what was published to the graph #1391).
• Schemas and Mappings cache on the page's latest revision id, so an approval change with no page edit does not take
  effect until that page is edited or the entry expires; and a Subject is validated against the published Schema
  while the Schema editor shows the latest one (Configuration-page caches and the Mapping trigger do not know the revision policy exists #1392).
• Undelete and import take the save path, so a restored page whose latest revision is unpublished comes back
  addressable but absent from the graph until the approval extension reprojects it.

Considered, omitted

• Collapsing the two publishing methods into one nullable substitution. It reads as a reduction, but it forces every
  draft save to resolve and re-project a revision the graph already holds, and it was what dragged the index and the
  editor into the design.
• Making the index follow the published revision, or hold the union of both. The first breaks editing as described
  above; the second leaves the maintenance rebuilder unable to remove a row, which is the one thing it exists to do.

Not in this change

The decision itself is not recorded in an ADR. docs/AGENTS.md says an ADR is a dated record, not retro-edited
apart from status links, so an earlier revision of this branch that appended to ADR 27 and ADR 32 has been reverted.
Revision choice wants its own ADR.

_{AI-authored — Claude Code, Fable 5.1 after a mid-session model switch from Opus 5 (1M context), which wrote the first design; implemented from #1379 on @alistair3149's go-ahead, redesigned after a five-pass review found the first design broke editing, then hardened after a second six-pass review; diff not yet human-reviewed; phpcs and phpstan clean, nine touched test classes pass locally including one that drives the registered policy through NeoWikiExtension's real wiring into Neo4j, CI on the previous push green across MW 1.43–master.}

[JeroenDeDauw]

Rebased onto master to resolve the conflicts with #1386, which dropped the $user argument from OnRevisionCreatedHandler::onRevisionCreated() and from the page-properties source (the revision now supplies its own author). Besides the two textual conflicts, that change reached three spots of this branch that git had merged silently:

• PageRebuilder now hands the handler the revision alone, after the policy substitution.
• The two new handler tests call onRevisionCreated( $revision ) without the user argument.
• The three new PageRebuilderTest cases use master's spy, which records a plain list of revisions. The assertion that the published revision brings its own author went with the parameter it tested: the handler now reads the author from whatever revision it is given, so [ $published ] being what the handler received covers it.

Committed separately: two fwrite( STDERR, … ) debug dumps left in PageRefreshWithoutEditTest, which printed on every run.

One interaction for the author's eye rather than a fix here. Master added two reprojection callers for #1246, onArticleRevisionVisibilitySet and LastEditorPagesRebuilder, and both go through rebuildFromPrimary(), which this branch defines as the non-substituting path. With a policy registered, a page whose latest revision is unpublished is handed to the handler as that latest revision, publishesRevision() declines it, and the hidden name stays in the graph until the approval extension reprojects the page. No draft content gets published by it, and it matches the undelete/import gap already listed in the description. Flagging it so that coupling "reads primary" to "does not substitute" stays a deliberate choice rather than an accident of the merge.

Verification: make cs clean; full local PHPUnit suite green (3233 tests, 10 skipped) before the debug cleanup, with the affected class re-run after it.

_{AI-authored — Claude Code, Fable 5.1 (max); one-line ask from @JeroenDeDauw to resolve the conflicts, no revisions; rebase and adaptations not yet human-reviewed; phpcs, phpstan and the full local PHPUnit suite run locally, CI pending on the new push.}