Docs hardening.

The Steam notes served a directory listing, not a page (#120)

* fix(routing): the Steam notes served a directory listing, not a page

All eleven of them, and every one is in the sitemap.

https://docs.deepcube.ai/DC/3D/steam/1.9.0 returned 200 with the title "Files
within public/DC/3D/steam/1.9.0/". A file index, not a release note. The same
was true of every version page.

CAUSE, reproduced locally against the real server with the real artifact. serve
resolves a path segment containing dots as a filename: path.extname("1.9.0") is
".0", so it never looks for index.html inside the directory and renders a
listing instead. cleanUrls then 301s /1.9.0/index.html back to /1.9.0/, so the
two rules chase each other and the page is unreachable by any URL.

MkDocs was building all eleven correctly. This was purely the serving layer.

FIX. Renamed the notes to dotless -- 1.9.0.md becomes 1-9-0.md -- which serves
correctly; verified both forms side by side against serve before committing.
Redirects added in both maps so the published URLs keep resolving, and the
IAPM-era redirects are retargeted straight to the new paths rather than chained
through the old ones, which would have made them two hops.

Also turned off directoryListing. A docs site has nothing to gain from serving
a file index, and this failure is exactly why: a listing returns 200, so
anything checking only status codes sees a healthy page.

The routing suite already knew that shape. Its comment says a directory listing
returns 200 "which is how cleanUrls:false shipped past a suite that only
asserted status codes. Check the TITLE." It had no case on these paths, so the
same failure shipped again somewhere it was not looking. Added two, one dotted-
version page and the newest note.

Verified: strict build clean, redirect parity clean, meta descriptions clean,
routing suite green, and by hand -- /DC/3D/steam/1.9.0/ now 301s to
/DC/3D/steam/1-9-0/ which serves the page, and /IAPM/3D/steam/1.9.0/ reaches it
in one hop.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* ci: fetch full history so the revision-date plugin can date renamed pages

The Steam rename failed CI. Not the routing change itself: mkdocs build
--strict aborted on eleven warnings from git-revision-date-localized, one per
renamed page.

actions/checkout defaults to a depth-1 clone. A file renamed in the commit under
test has no history at that depth, so the plugin cannot date it and warns, and
--strict turns a warning into a failed build. The plugin's own message names the
fix: "Try setting fetch-depth: 0 in your GitHub Action."

It passed locally because a developer clone has full history, which is exactly
the class of failure that only appears in CI.

Worth noting beyond this PR: the warning is about dates being WRONG, not only
missing. Every page carries a "last updated" stamp from this plugin, and on a
shallow clone that stamp is only as good as the history fetched. This makes
those dates correct rather than incidental.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>