The special page displays a human-readable label for the topic, sourced from the Wikidata item whose QID appears in the URL suffix. This is a distinct data path from the M0 durable cache: the label is a small piece of metadata that changes independently of the rendered article content and comes from Wikidata directly rather than being baked into the cached blob. Fetching it separately on each render is acceptable as long as it is cached appropriately on the client wiki side.

Implementation notes:

• Use Wikibase client as the label source when it is installed on the client wiki (which, for Test Wikipedia and every Wikipedia we plausibly enable in the future, will be the case). This gives us the existing Wikibase label caching, language fallback, and item-resolution infrastructure for free, and avoids inventing a parallel cross-wiki read path to Wikidata. Loading WikiLambda on a client wiki without Wikibase client should produce a clear configuration error rather than a silent fallback to raw API calls.
• Language-selection policy: the label is shown in the same language as the article content (i.e. driven by uselang and the UI-language fallback chain established by the parent bullet), not independently selected, so that a reader viewing the French rendering of an article does not see an English label next to French content. If no label exists in the selected language or any language in its fallback chain, the page falls back to the QID itself rather than showing an empty title — this is the same policy Wikibase client uses for label-less items today and it behaves predictably.
• Place the label in two positions on the rendered page: as the page title (via OutputPage::setPageTitle, matching the repo-side SpecialViewAbstract behaviour) and as an inline heading at the top of the rendered article body. Both are required: the page title anchors the browser tab, skin chrome, and history entries, while the inline heading is what the reader actually reads above the content. The two populate from the same fetched label, so drift between them is not a concern.
• Handle QID-does-not-exist and QID-is-a-redirect cases explicitly. A non-existent QID should produce a clear error page (with a message distinct from "no Abstract Content exists for this topic", since the two failures have different diagnoses). A redirected QID should follow the redirect transparently for the reader and keep the requested QID in the URL; detection and logging of such redirects so that the pre-generation input set can be updated is an M0 concern (see the pre-generator's redirect sub-bullet) and is not M1's responsibility.

Acceptance criteria:

• Wikibase client is a declared hard dependency of abstract client mode; loading WikiLambda on a wiki with abstract-client enabled but without Wikibase client produces a clear configuration error.
• The label is fetched via Wikibase client, with no parallel raw-API code path.
• The label is displayed both as the page title (via OutputPage::setPageTitle) and as an inline heading at the top of the rendered article body, populated from the same fetched value.
• A non-existent QID produces an error page distinct from "no Abstract Content exists for this topic".
• A redirected QID follows the redirect transparently for the reader while keeping the requested QID in the URL; no logging is required here because pre-generator redirect detection is the M0 bullet that owns the upstream tracking.