feat(special): add Special:MostLinkedCategories report

[bohdansolovie]

Summary

Adds the Special:MostLinkedCategories maintenance report (MediaWiki's "Most used categories") at /wiki/special/mostlinkedcategories.json: the wiki's topics ranked by how many published articles are tagged with each one, most-used first.

• scripts/most-linked-categories.js — pure buildMostLinkedCategories({ categoriesIndex }) ranking helper.
• src/pages/wiki/special/mostlinkedcategories.json.ts — the JSON endpoint.
• scripts/check-most-linked-categories.js — regression check (unit tests + built-output contract + sibling cross-check), wired into postbuild and a test:most-linked-categories script.

Why This Should Ship

The existing Special:Categories index lists topics alphabetically, so nothing on the site surfaces which topics are largest / best-covered (or which are nearly empty). This is the category-side counterpart to the existing Special:MostLinkedPages, and completes the set of MediaWiki topic-maintenance reports for editors and programmatic consumers (dashboards, navigation, coverage tooling). On the current content it ranks 41 topics, top Subnets (253 articles) down to single-article topics.

It reuses the same public/data/categories.json artifact the Special:Categories page already reads and the same categorySlug / compareTitles helpers, so the two surfaces can never disagree on which topics exist or how many articles each has — only the ordering differs. Distinct-member counting and empty-topic dropping match buildCategories exactly, so a duplicated frontmatter category can't inflate a rank.

Review Notes

• JSON-only endpoint — no HTML page, no navigation entry, no visual change (same pattern as Special:WantedPages / Special:LonelyPages / Special:DeadEndPages).
• Each entry exposes the same per-topic hub/feed companion URLs categories.json does (url, articlesUrl/articlesJsonUrl, feedUrl/feedJsonUrl, atomUrl, rssUrl) for consistency across the two orderings.
• npm run build passes end-to-end (all existing postbuild checks + the new check-most-linked-categories.js). The new check unit-tests the ranking (distinct counts, empty-topic drop, numeric tie ordering), re-derives the expected report from categories.json and asserts the built JSON field-for-field in count-desc order, and cross-checks the sibling categories.json so the two can't drift.
• Not added to the sitemap, matching the other JSON-only special reports.

Target Branch

• This PR targets test
• This PR targets main only because it promotes test to production

Security Checklist

• No secrets, tokens, build hooks, wallet seeds, or private endpoints are included
• No unnecessary workflow, dependency, or deployment changes

[taopedia-site-maintainer]

Verdict: Close

Final action: close.

PR #1975: feat(special): add Special:MostLinkedCategories report

Codex and Claude both found this should not merge.

Codex review:
The diff is coherent and the reported build validation is clean, but it fails the maintainer's necessity test for non-visual changes. If this PR is not merged, no existing Taopedia route, static build, deploy, rendered data, accessibility behavior, or real security exposure breaks or degrades.

The new /wiki/special/mostlinkedcategories.json endpoint is an additional programmatic report that ranks existing category data by article count. That may be useful for editors or downstream tooling, but the PR does not show that anything currently depends on this route or that the existing site is producing incorrect data without it. The existing Special:Categories data remains available; this PR adds another ordering and companion regression check. Under the stated policy, that is a nice-to-have expansion of the non-visual surface, not a necessary fix.

Because this adds a permanent endpoint plus postbuild maintenance code without removing a present harm, it should not be merged as-is.

Claude advisory review:
Verdict: Request changes

Reasoning:

• The necessity test fails: if this PR is not merged, nothing breaks or degrades for any real user. Special:Categories already exposes every topic with its article count, just alphabetically. This PR adds a second ordering of the same data that no existing code, user, or documented downstream tool consumes.
• The PR's own framing confirms this is additive ("completes the set of MediaWiki topic-maintenance reports", "nothing surfaces which topics are largest") — a missing feature, not a broken one. The site already surfaces all category coverage data; it just isn't sorted by count.
• "Counterpart to Special:MostLinkedPages" is pattern-completion reasoning, not a present harm. The existence of a parallel sibling does not make this sibling necessary.
• The implementation is technically clean and the check script is thorough, but quality does not override necessity.

Risks:

• New permanent JSON endpoint (/wiki/special/mostlinkedcategories.json) with no declared consumer and no path to removal once external tools take a dependency.
• New postbuild entry lengthens every CI build for no current user-facing benefit.
• The check script imports buildMostLinkedCategories from the new helper AND re-derives the expected ranking using the same function — so a systematic bug in the ranking logic would pass both the unit tests and the built-output contract check simultaneously (they share the source of truth, which is correct by construction but not independently verified).

Why closed:

• The final action is close, even if one advisory reviewer approved.
• Both automated reviewers must approve this class of PR before it can merge.

---

Automated review by Taopedia Site Maintainer.