Expose the page namespace ID through PageIdentifiers and the subject REST API

[JeroenDeDauw]

Implements a read-path follow-up @JeroenDeDauw asked for after the #946 review: expose the canonical namespace ID so API/Cypher consumers don't have to parse the content-language page-title prefix.
Context: the NeoWiki codebase, PR #946, the PageIdentifiers → GetSubject/GetPageSubjects → REST chain, and MediaWiki namespace localization.
_{Written by Claude Code, Opus 4.8 (1M context)}

Follows-up to #946

The page node carries a canonical namespaceId (added in #946), but it was only reachable via Cypher. Read code and the subject REST API exposed only the page title (name, the content-language prefixed string), so a consumer needing the namespace had to parse that locale-dependent prefix — the fragility namespaceId exists to avoid. Since the graph is itself a public surface (users author Cypher against the node properties), the canonical ID belongs on the read/API surface too.

This change:

• adds namespaceId to the PageIdentifiers domain object;
• reads it from the page node in Neo4jPageIdentifiersLookup;
• exposes it as pageNamespaceId in the GetSubject and GetPageSubjects REST responses, alongside pageId and pageTitle.

pageNamespaceId is a canonical, language-independent integer (e.g. 0 main, 12 Help), stable across wikis and content languages.

The frontend is unchanged: its only consumer builds same-wiki relation links from pageTitle via mw.util.getUrl and does not need the namespace yet.

Verification

• Tests added/extended at each layer: Neo4jPageIdentifiersLookupTest (lookup reads the stored ID), GetSubjectQueryTest / GetPageSubjectsQueryTest (query threads it through), GetSubjectApiTest (REST JSON exposes pageNamespaceId). Both new behaviours were seen failing via mutation (wrong ID in the lookup; dropped field in the presenter).
• Full PHPUnit suite (1345 tests), phpcs and phpstan green.

🤖 Generated with Claude Code