fix(build): redirect the legacy /next/ URLs instead of 404ing

[kw-tmueller]

Fixes #111.

Problem

On the pre-monorepo site, next was the version segment of each product's upstream master build. This repo publishes real version numbers only, so every inbound …/next/… link and every indexed next page dead-ended after the cutover.

The issue suggests mapping /next/* → /dev/*, but no /dev/ path exists or should — the README's versioning rules deliberately forbid a moving source folder. The in-development line already lives at its real number marked prerelease: true, so that is what legacy next actually became.

What this does

antora-extensions/next-alias.js publishes a /<product>/next/ tree the same way latest-alias.js publishes latest: static meta-refresh stubs, noindex, canonical pointing at the real page, one hop to real content. Per component it targets:

/next/ URL	redirects to	why
/ocis/next/	/ocis/8.3/	prerelease dev line
/desktop/next/	/desktop/7.2/	prerelease dev line
/android/next/	/android/4.8/	prerelease dev line
/server/next/	/server/11.0/	no dev line — latest release
/ios-app/next/	/ios-app/12.7/	no dev line — latest release
/webui/next/…	/webui/…	versionless component
/next/	still 404	ROOT was versionless on the legacy site too

Per page, anything the dev line dropped falls back to the latest release, so a legacy URL never dead-ends when it has any live equivalent.

webui is included because docs-webui only ever had master (sync/manifest.yml), so all of its legacy URLs were /webui/next/**. The ROOT landing component is excluded: a /next/ tree there would invent URLs rather than rescue them.

639 stubs across the six components. Deep paths follow the dev line's own page-aliases moves — e.g. /ocis/next/deployment/services/s-list/proxy.html → /ocis/8.3/admin/deployment/…, where ocis relocated that page.

Changes

• antora-extensions/next-alias.js (new) — publishes the tree; target derived from the prerelease flag, so release rollover needs no bookkeeping.
• antora-extensions/lib/alias-tree.js (new) — the catalog mirroring both alias extensions need, extracted from latest-alias.js, which keeps only what is specific to latest (−45 lines, no behavior change; its existing tests pass untouched).
• ui/supplemental/js/go-redirect.js — next joins PUBLISHED_VERSIONS: /server/next/go.php?to=<key> now resolves inside the tree, and that list is asserted against the published public/server/* segments in both directions.
• test/next-alias.test.js (new) — build-output guards plus fake-catalog unit tests for the precedence rules the current content cannot exercise (prerelease wins; a dev-line rename beats an older real page; versionless no-double-add; ROOT skipped; latestPrerelease backstop).
• README / agents.md / site.yml — record that latest and next are generated, never source folders, and that next tracks the prerelease flag.

Verification

npm run antora && npm test → 42 pass, 0 fail, 1 skip. The skip is honest: today every release page also exists in the prerelease line, so the release-only fallback has no live case to assert — the unit tests cover that path instead.

Also confirmed on the built site: no /next/ URL in any sitemap, and none in the Pagefind index (485 pages indexed, no redirect-stub fragments) — the same treatment /latest/ already gets.

Out of scope

The content has 35 broken xref:next@ocis:… / next@server:… cross-references (29 of them in content/main/modules/ROOT/pages/ocis_release_notes.adoc) that error on every build, including before this PR. They reference a next component version, which a redirect tree cannot supply — Antora resolves those xrefs before any redirect exists. They need editing to real version numbers; worth its own issue.

🤖 Generated with Claude Code

[dj4oC]

LGTM