Restore the documented status-code contract of DELETE /subject/{id}

[alistair3149]

Fixes #1312

DELETE /neowiki/v0/subject/{subjectId} broke the status-code contract thatdocs/api/rest-api.md documents and ADR 027 governs, in four ways.

The read gate

The action resolved the Subject to its page and authorized the write against that page, but never
checked the caller may read it — unlike ReplaceSubjectAction and UpdateStatementAction. Two
consequences: a Subject on an unreadable page answered 403 where the contract promises 404, so
403 versus 404 told a caller which Subject ids exist; and a caller holding edit but not read
could delete Subjects there.

The action now takes a PageReadAuthorizer and answers the not-found path before reaching the write
check — the shape UpdateStatementAction::getPageOfSubjectToEdit() already uses. A page the caller
can read still answers 403 when they cannot edit it.

Three further breaches of the same contract

A malformed id answered 500. new SubjectId( 'notavalidid' ) throws
InvalidArgumentException, a LogicException, which no catch arm matched. It now answers 400, as
every sibling Subject-keyed handler does.

Internal failures answered 403 carrying their own message. The handler caught every
RuntimeException and reported it as a permission denial, so a DBError raised inside the
authorizers surfaced as 403 {"message": "<internal error text>"} — and the read gate added here
runs the getUserPermissionsErrors hook, which is arbitrary ACL-extension code. The delete denial
now raises the typed SubjectEditNotAuthorizedException, keeping its own message, and an internal
error is a 500.

A delete that removed nothing answered 200. SubjectRepository::deleteSubject() returned
void and the implementation discarded the write's outcome. It now returns
PageContentSavingStatus, as savePageSubjects() already does, and the action answers not-found
unless a revision was created. The repository asks the slot whether it still holds the Subject
rather than inferring removal from the save: mutatePageSubjects re-serializes the slot whatever
the mutation did, so a slot written by anything other than the serializer — an import, or
Special:NeoJson — yields new bytes and a real revision even when nothing was removed.

Open for review

A write the wiki refuses — read-only mode, an edit-filter abort — now answers 404 Subject not found while the Subject still exists. CreateSubjectAction, SetMainSubjectAction,
SetSubjectsOrderingAction and MoveSubjectAction all map ERROR to a not-found presentation, so
the shape is the established one, and it replaces a false 200. Giving ERROR its own answer is
the alternative, and the one that would keep the documented 404 causes exact. Left as it is here
because the choice belongs to all five endpoints at once, not to this one.

Considered, omitted

Sharing the resolve-then-read-gate half with Application\Rdf\SubjectHostingPageResolver. Adopting
it here alone would leave the three Subject-id-keyed write actions in three different shapes, and
moving it out of the Rdf namespace reaches past this fix. Worth doing across all of them at once.

Not fixed here

#1383 — Special:NeoJson reads and
writes Subject content with no read gate at all, the same threat model on a path that is not a REST
route. It is unregistered unless $wgNeoWikiEnableDevelopmentUI is set, which defaults to false.

_{AI-authored — Claude Code, Opus 5 (1M context); one-line ask from @alistair3149, who then widened the scope to the endpoint's whole contract; diff not yet human-reviewed; the read gate verified failing against five mutations of it with no survivors, the later guards not mutation-tested (the local runner became unstable); make cs clean, non-Database suite (2002 tests) plus the DeleteSubject, MediaWikiSubjectRepository and NoGraphBackend classes green locally, full suite green on CI.}