Make the Subject label optional

[alistair3149]

Fixes #1283

A Subject may now have no label. The slot omits the key, and a blank label is read as absence, so the two cannot drift
apart. Display falls back at the point of use — a Main Subject to its page name, every other Subject to its Schema
name — held in one rule, SubjectDisplayName, mirrored for the creator by placeholderSubjectLabel.ts.

The requirement was enforced in three independent layers, all dropped together: the label-required violation, hard
guards in the create and replace Actions, and PARAM_REQUIRED on four endpoints. Relaxing fewer would have been
invisible from the API.

Decisions worth a look:

• The graph materializes the fallback for Main Subjects only. The Schema name there would make every unnamed
  Subject of a Schema indistinguishable in query results, and the Schema is already the node's second label. That
  makes an absent name no longer the mark of a stub, so the orphan sweep now identifies one by its node labels —
  the old oracle would have deleted real Subjects.
• rdfs:label always falls back; a Mapping's labelPredicate does not. That term states what the thing is
  called in the target ontology, and a Schema name under foaf:name would assert a type as a name, which
  reconciliation keys on.
• Lua diverges from REST on purpose. subject.label is the display name and subject.storedLabel the nullable
  stored one, because an absent key is nil in Lua and concatenating it replaces the rendered page with a script
  error. REST splits them the other way, with a nullable label and a non-null displayName.
• PUT is a full replacement, so an omitted label clears a stored one.

NeoWiki:ClearDefaultSubjectLabels clears pre-existing stored defaults once. It is load-bearing rather than polish:
the stale-label fix only reaches Subjects that have no stored label, so without it existing Subjects keep the bug.

Considered, omitted:

• Making the display name configurable. #1140 is
  titled "configurable / extendable", but its body asks for an outcome — stop showing the page name, show the Schema
  name — which this delivers. The consumer with the strongest claim renders its own subject column from the REST API
  and now receives label, displayName and schema, so it needs no server-side hook. If configurability does
  arrive it is most likely Schema-authored data, for the identical-siblings case, which wants more arguments to a
  pure function rather than dependency injection.
• Discriminating several label-less Child Subjects of one Schema. They still display identically. The fallback
  can gain discriminators later without touching stored data, which stored defaults could not.

Known gaps, not fixed here: ?oldid= views resolve main-ness from the live page, so a historical label-less Subject
can be named from today's state; and GET /subject-labels returns a computed page name in its label field for a
label-less Main Subject without saying so.

Manual Browser Check

1. On a page with no Subjects, open "Create subject" and pick a schema: the label field shows the page name greyed as
   a placeholder, and the field itself is empty. On a page that already has a Main Subject, it shows the schema
   name instead.
2. Save without typing a label. The new Subject appears under that name, and action=raw&slot=neo shows its entry
   with no label key.
3. Open that Subject in the editor: the title and the rename field show the same fallback as a placeholder. Edit only
   a statement and save — a labelled Subject must keep its label (the field round-trips the stored value, not the
   placeholder).
4. GET /rest.php/neowiki/v0/subject/<id> returns "label": null beside a non-null "displayName".
5. Relation autocomplete still finds Subjects by name; a label-less Child Subject is absent from it by design.

_{AI-authored — Claude Code, Opus 5 (xhigh); design authored by @alistair3149 in #1283 and followed as written, with his redirections on ADR non-modification, doc trimming, and the YAGNI call above; implementation and review fanned out across subagents, then a code review, a design review and a blind text review, of which 18 of 34 findings survived adversarial verification; human review in progress. Verified: phpcs, phpstan, 1904 unit tests, every @group Database class run individually, 1369 vitest, lint and build; browser-verified on a dev wiki including the creator placeholder, a blank save storing no label, the graph name policy, EDM foaf:name skipped without a stored label, the migration clearing 77 real labels, and a page move renaming a label-less Subject.}