Add pinned out-of-date banner and /latest/ canonicals for versioned docs

[miharp]

Part of #320.

Addresses @binford2k's concern in #320 that bookmarks and search results will keep pointing at old versions once a product cuts a new major.

Pinned out-of-date banner

Every page of a frozen (non-latest) doc version now shows a notice pinned to the bottom of the viewport, linking to the product's /latest/ docs. Coverage is derived from _data/products.yml: nothing renders today (every numbered version is still its product's latest), but the moment a product gains a new version and its latest key moves, all pages of the older collections show the banner automatically — no per-page front matter. Like the version picker, the banners live outside the Turbo content frame and are re-synced on each frame load.

The banner links to the product's /latest/ root rather than the same page under /latest/, because we have no redirect mechanism and a same-page link would 404 whenever a page was renamed or removed in the newer version. Once the 404 page grows a "search for this page" affordance (tracked in #438), we can revisit a same-page link.

Update: the original version of this logic banner-ed any version that wasn't latest, which is wrong during a Phase 1 major-version cutover (see MAINTAINING.md) — a new version can sit ahead of latest in _data/products.yml as a beta preview, deliberately not yet promoted (this is exactly the shape #430's OpenVox 9 cutover takes). That preview version is not "no longer actively updated," so it must not get this banner. Fixed by tracking whether the loop has passed the latest entry in the (documented newest-first) versions list and only emitting the banner after that point.

Verified three ways:

• A standalone Liquid render against synthetic 9x / 8x (latest) / 7x data: 9x and 8x render no banner, 7x renders one.
• Live, merged locally against the real docs/openvox9-cutover branch (not part of this PR) via jekyll serve: no banner on /openvox/9.x/ or /openvox/8.x/.
• A temporary synthetic older version confirmed the banner still renders correctly (and looks right) when a version genuinely is older than latest.

Screenshots below: OpenVox 9.x (preview, no banner), OpenVox 8.x (latest, no banner), and a synthetic older version (banner shown, for comparison).

CI check for products.yml consistency

The banner logic above (and the version selector) both depend on an unenforced convention: versions listed newest-first, and latest naming a real entry in that list. Nothing previously caught a violation of either — a misordered list or a typo'd latest would silently mis-derive every version's state. Added rake test:products_data, wired into the Rake Checks CI job, which validates: latest resolves to a real version id, version ids are unique, and ids sort newest-first (by leading version number). Verified it passes against both the current products.yml and the real docs/openvox9-cutover data, and correctly fails against injected bad-ordering, duplicate-id, and unknown-latest cases.

Canonical URLs for the numbered/latest duplicate pair

While latest points at a numbered version, that collection publishes byte-identical content under two URLs (e.g. /openvox/8.x/... and /openvox/latest/...). A small Jekyll hook (_plugins/canonical_latest.rb) now sets page.canonical_url on the numbered copy pointing at its /latest/ twin; the theme's head.html already honors that key, so search engines index the stable /latest/ URLs instead of splitting ranking across the pair. Frozen versions keep their default self-canonical, since their content is unique once latest moves on.

Note for #401: jekyll-seo-tag also honors page.canonical_url, so this composes with the SEO-tags work rather than conflicting with it.

[binford2k]

I suspect that you started by looking for an existing plugin for the CanonicalLatest functionality, but just wanted to double check.

[miharp]

Off-the-shelf canonical plugins only emit self-referential URLs or pass through front matter; the part that needed code is computing the numbered-to-/latest/ mapping from _data/products.yml and the symlink layout, which is specific to this repo's version model. That mapping is all the hook does.