Key parser-cached output by the parsing user's access class

[alistair3149]

For #1059

Follows-up to #1346

With the parse-time gates in place, the parser cache still served whatever the last parse produced to every reader: a sysop's parse cached restricted values for anonymous readers, and an anonymous parse cached gaps for sysops. Such output is now keyed by the parsing user's access class.

• A cache-varying parser option, neowikiAccessClass, registered through ParserOptionsRegister. It carries no value; the class enters the key through the PageRenderingHash hook, and only for a page whose parse recorded the option. A lazily valued option would instead be loaded for every logged-in edit of every page by core's cache-key comparison, pushing all of them onto the deferred parser-cache path.
• The class itself, from UserAccessClass, is the parsing user's effective groups plus the wiki-level read and neowiki-query decisions, as a readable string such as *,autoconfirmed,user;read;query. Group names are encoded, since they reach the class from hooks and the database and could otherwise be named to describe like another set of groups. Every reader gets a class, the anonymous one included, so a page that reads Subjects never reuses an entry cached before this change and no upgrade purge is needed.
• Obtaining the parsing authority (ParserAuthority::of) records the option, so every gated read keys its page by access class without a call site having to remember to. {{#view}} now resolves its page's Main Subject through the public PageSubjectsLookup instead of a parsing authority, so it keeps one entry as before.
• ADR 27's open decision on parse-time semantics resolves to this rule. The alternatives weighed (a fixed anonymous authority, post-cache trimming, a cache-off operating rule) are recorded under Alternatives Considered.

The class is a proxy for the permission hooks: exact wherever page access follows group membership, wrong for hooks that grant per user, which is why such wikis must run with the parser cache off. The installation docs now say so next to the rights. Installs with restricted content need one refreshLinks run, noted in the upgrading docs, because MediaWiki rewrites categories and page properties only on an edit.

Not solved here, and now stated in ADR 27's consequences: data derived from the canonical parse (categories, page properties, links tables, the Page node's categories in graph projections) is computed as the anonymous user, so on a wiki where anonymous users cannot read, a category derived from a parse-time read is never set. A designated reader for canonical parses would lift that; it needs a decision.

Manual Browser Check

1. With the parser cache enabled, restrict a page's read permission for anonymous users (for example with the Lockdown extension) and give it a Subject with a text property.
2. On a second page, save {{#neowiki_value: <property> | page=<restricted page>}} as a sysop and view it: the value shows.
3. View that page logged out, without purging: the value is absent. Log back in and view it again: the value shows. Each access class keeps its own cached copy.

_{AI-authored — Claude Code, Fable 5.1 for the implementation, Opus 5 for the review fixes; same design discussion as #1346, no redirects during implementation; same-session AI review applied across six passes, diff not yet human-reviewed; tests written first and mutation-checked, phpcs/phpstan clean, the full non-Database suite and the touched Database classes green locally, CI green.}