Ordinary MediaWiki special pages have no article-related tabs; readers land on them and see no "edit / history / talk" chrome at all. For the Abstract Content special page to feel like something a reader is reading rather than a utility page, M1 has to synthesise that chrome on the special-page output and wire each tab to the right cross-wiki destination — almost all of them on abstract.wikipedia.org, since that is where the underlying content actually lives. The repo-side SpecialViewAbstract already does some of this work for the in-wiki case (e.g. setting the relevant title so edit/history links work against a local page); the client-side version needs the same treatment but with its link targets pointing off-wiki.

Implementation notes:

• Enumerate the tabs the client-side page will synthesise and commit to a cross-wiki target for each. View stays local (it is the current page). Edit, history, talk, and "what links here" all point at the corresponding abstract.wikipedia.org page for the same QID. Watchstar, delete, protect, and move do not appear at all on the client side — they are meaningless for a read-only cross-wiki render and should not render rather than rendering as disabled. This sub-bullet captures the decision to fix that enumeration during M1, with the specific list above as the working default to be confirmed with Design.
• Use the abstract: interwiki prefix, not hard-coded URLs, for the cross-wiki link targets. The abstract: prefix (configured per-wiki in the interwiki table) is the stable way to reach abstract.wikipedia.org from a client wiki, and using it means link generation survives any future rename or relocation of the repo wiki without code changes.
• Leave the logged-in vs logged-out cross-wiki handoff entirely to CentralAuth/SUL. A reader who clicks "edit" on the client-side page ends up on abstract.wikipedia.org's edit interface and their login state there is handled by the existing SUL flow; M1 does nothing special to preserve or extend session state across the handoff. This bullet is positive rather than silent specifically so that an implementer does not invent a custom session-passing scheme unprompted.
• Preserve the skin chrome across desktop and mobile. The synthesised tabs must appear in the expected place on Vector/Vector 2022 (page-level tabs at the top) and on Minerva (the mobile overflow menu). Mobile is the more fragile case because Minerva's overflow-menu API for extension-provided actions has fewer conventions; the implementer should expect to spend more time on mobile parity than on desktop.

Acceptance criteria:

• The special page renders article-like skin chrome (page-level tabs on Vector, overflow-menu entries on Minerva) in place of the default special-page chrome.
• The View tab is local; Edit, History, Talk, and What Links Here point at the corresponding abstract.wikipedia.org page for the same QID via the abstract: interwiki prefix, not via hard-coded URLs.
• Watchstar, Delete, Protect, and Move are absent from the rendered chrome (not rendered disabled, not rendered at all).
• Cross-wiki handoff for logged-in users relies on the existing CentralAuth/SUL flow, with no custom session-passing code added.
• Mobile (Minerva) parity is verified on a real mobile device or emulator, not only in desktop responsive mode.