Support trailing-slash URLs

[gativarshney]

Fixes #207.

Summary

This fixes broken URLs caused by inconsistent trailing-slash handling between the repository and the deployed GitHub Pages site.

The site now:

• accepts both /page and /page/
• keeps /page as the canonical URL
• generates internal links without trailing slashes
• generates canonical and sitemap URLs without trailing slashes
• generates RSS <link> URLs without trailing slashes
• preserves existing RSS <guid> values
• keeps old trailing-slash URLs working through static aliases

The site root itself remains https://openprinting.github.io/, in the sitemap and RSS channel link.

Root cause

deploy.yml passed static_site_generator: next to actions/configure-pages.

The action does not recognize this repository's next.config.ts and generated a next.config.js, which Next.js preferred over the repository configuration.

As a result, the deployed build used different trailing-slash behavior from the repository configuration and exported flat routes such as page.html. GitHub Pages served /page but returned 404 for /page/.

Because only the deploy workflow injected that generated config, local and PR builds used the repository configuration and produced the opposite layout, which is why this did not reproduce outside production.

Several URL generators also explicitly produced trailing-slash URLs, including the RSS feed, sitemap, canonical URLs, Foomatic legacy redirects, and internal Markdown links.

The RSS issue is what caused external links, including those consumed by LWN, to return 404.

Fix

• Remove static_site_generator: next so the repository's next.config.ts is used during deployment.
• Explicitly set trailingSlash: false, keeping /page canonical.
• Generate page/index.html aliases so existing /page/ URLs continue to work.
• Normalize internal, canonical, sitemap, and RSS <link> URLs to the slashless form.
• Update Foomatic legacy redirect targets.
• Remove trailing slashes from site-internal Markdown links.
• Add verify:urls to CI and the deployment workflow. It reads ./out and rebuilds nothing, so a broken export cannot be deployed.

RSS <guid> values are intentionally preserved in their historical form because they represent feed-item identity. Changing them could cause existing articles to be treated as new items by feed readers.

Note that /page/ answers 200 with an instant meta-refresh rather than a 301. GitHub Pages cannot issue real redirects for static files. Each alias is noindex with rel="canonical" pointing at /page, so the canonical URL remains the slashless form.

Verification

• TypeScript check passes.
• Next.js lint passes.
• yarn verify:urls passes.
• 7,572 exported routes have both URL forms available.
• All RSS item links and GUIDs resolve.
• RSS output is well-formed XML.
• 103 Markdown files were updated only for the intended trailing-slash link changes.
• /cups/ was intentionally preserved because it belongs to the separate CUPS Pages site.
• Representative routes were manually verified locally with and without the trailing slash.

The alias approach relies on GitHub Pages serving page.html for /page while page/index.html handles /page/. This was verified against a live GitHub Pages site that has both files present, but the precedence behavior is not explicitly documented by GitHub.

After deployment I will confirm both forms directly on openprinting.github.io:

curl -sI https://openprinting.github.io/news | head -1
curl -sI https://openprinting.github.io/news/ | head -1

Both should return 200. If /news were ever answered with a 301 instead, the precedence assumption would be wrong and this should be reverted; the aliases would then need to contain full page copies rather than redirects.