Harden Subject-write authorization on the server and align the frontend hints

[alistair3149]

Follows-up #986
Stacked on #1002

Hardens Subject-write authorization on both the server and the frontend. The server change is the substance; the frontend commits (merged in from #1019) align the browser-side permission hints with it.

Server

The Subject write actions (create, replace, delete, set main, set ordering) authorized their writes with Authority::definitelyCan('edit', $title). definitelyCan reads permissions from a replica (RIGOR_FULL) and checks the edit rate limit without counting the hit, so these writes never consume the edit throttle. API- and agent-driven bulk writes therefore bypass rate limiting, and a block or protection applied moments earlier can be missed due to replication lag.

SubjectAuthorizer::authorizeEdit() now performs the write authorization via Authority::authorizeWrite('edit', $title), which uses RIGOR_SECURE (primary reads) and counts the write against the edit rate limit. All five write actions use it. Because every Subject write is an edit of the owning page, the previous per-operation create-main/create-child authorization distinction collapses into this single check.

Special:NeoJson edits Subject content directly rather than through these actions, so its onSubmit write now authorizes via authorizeEdit as well; its execute keeps the side-effect-free canEditSubject for early denial before the form is rendered. No Subject write path is left on definitelyCan.

The can* checks remain for UI hints (page tools, the RedHerb sidebar) and that early Special:NeoJson gate, so ordinary page views neither enforce nor consume the edit rate limit. The now-unused canDeleteSubject is removed. Each write action's authorization test pins it to authorizeEdit: reverting an action to a can* hint fails its test.

SubjectAuthorizer is also split along the line its callers already follow: SubjectPermissionHints (side-effect-free capability queries) and SubjectWriteAuthorizer (the binding, rate-limit-counting write gate). Passing a write action a hint no longer type checks, and a render path can no longer consume rate-limit allowance by accident. AuthorityBasedSubjectAuthorizer implements both. The unused SchemaAuthorizer is removed, since Schema and Layout writes go through MediaWiki's normal edit machinery.

Part of the permission audit tracked in #101.

Frontend

The frontend permission hints disagreed with the server: canDeleteSubject hinted on the delete right and the two creation hints on createpage plus edit, while the server authorizes every Subject write as an edit. The delete right is sysop-only by default, so the delete affordance in the subjects manager was hidden from ordinary editors who are in fact allowed to delete a Subject. All four hints now check edit, mirroring AuthorityBasedSubjectAuthorizer.

Because the frontend has no binding authorization and cannot have any, the SubjectAuthorizer, SchemaAuthorizer and LayoutAuthorizer interfaces (with their RightsBased* implementations, services, factories, and public-API exports) become *PermissionHints. The name is the documentation extension authors read off the public API: a positive answer means "offer the affordance", never "the write will succeed" — the same conflation the server split removes.

The hints remain wiki-global rather than per-page (a documented TODO): a user who may edit globally but not the page at hand is still offered affordances the server then rejects.

Verification

AuthorityBasedSubjectAuthorizerTest pins authorizeEdit to authorizeWrite (and the can* hints to definitelyCan); each write action's authorization test fails if the action is reverted to a can* hint.

Confirmed end-to-end against a running wiki, with the edit rate limit set to one edit per window — two back-to-back Subject writes via the REST API, as the same rate-limited user, on the same page:

#	Request	Result
1	POST /neowiki/v0/page/{id}/childSubjects	201 Created — consumes the edit allowance
2	identical request, immediately after	403 Forbidden — throttled by the edit rate limit

On the previous definitelyCan path, write #2 would also have returned 201, since that check never counts the throttle.

Frontend: make tsci is green — 99 test files, 1007 tests, with vue-tsc and eslint/stylelint clean. RightsBasedSubjectPermissionHintsTest pins the corrected rights: reverting canDeleteSubject to delete, or the creation hints to createpage, fails its assertions.

Directed by @alistair3149. The server change incorporates the #986 review, a follow-up code-review pass, and end-to-end rate-limit verification; the frontend alignment was merged in from #1019 (directed by @JeroenDeDauw) and re-verified here (make tsci reproduced green: 1007 tests, typecheck, lint).
Context: the NeoWiki codebase and MediaWiki Authority / PermissionManager / UserAuthority / RateLimiter internals.
_{Written by Claude Code, Opus 4.8 (1M context)}

[JeroenDeDauw]

There is an interface segregation issue now. Interestingly, Fable 5 max didn't catch it when looking from multiple angles, but it did when I asked "isn't it better to have two interfaces?". Got an Opus session running now with the implementation which will be pushed here after running review skills.