Verify GitHub Pages docs site reflects current version (v0.5.1b0)

[fsecada01]

Found while doing a README audit pass (2026-07-15). The pdoc-generated GitHub Pages docs site was showing version listings only up through v0.5.0b0, while pyproject.toml currently reports v0.5.1b0. Could be a caching/publish lag rather than a real gap — worth a manual check of whether the Pages deploy step actually ran for the latest tag/release and, if not, why (missing workflow trigger, failed step, etc.).

[fsecada01]

Investigation result: one-off deploy/CDN staleness, not a workflow bug — resolved

Root cause: Everything on GitHub's side of record was already correct before I touched anything:

• gh-pages branch content (versions.json, latest symlink) was correct, listing v0.5.1b0 as latest.
• The docs.yml run triggered by the v0.5.1b0 tag push (run 28549344517, 2026-07-01) completed successfully for both Build and Deploy jobs.
• The GitHub Pages deployments API confirmed that run as the most recent recorded deployment for the github-pages environment.

Despite all of that, the live site (https://fsecada01.github.io/component-framework/versions.json, cache-busted) was still serving stale content (latest: "v0.5.0b0", missing v0.5.1b0 from the list) as of today, 2026-07-20 — 19 days after the correct deploy was recorded. This points to a stuck/stale GitHub Pages CDN edge that never picked up the last artifact, rather than any bug in the workflow, the gh-pages store, or docs/update_gh_pages.py.

I also checked repos/.../pages: build_type is correctly "workflow" (Actions-based). It does return a vestigial source: {"branch":"master","path":"/"} field, but this is just legacy API metadata GitHub always includes regardless of build_type — it has no effect when build_type is workflow, so no config change was needed there.

Fix applied: Manually re-triggered the deploy via gh workflow run docs.yml --repo fsecada01/component-framework --ref master (run 29774684568). Both Build and Deploy jobs completed successfully in ~30s combined. No code/workflow changes were needed or made.

Confirmed fixed — live versions.json now matches the gh-pages branch:
```json
{
"versions": ["v0.3.1b0", "v0.4.0b0", "v0.4.1b0", "v0.5.0b0", "v0.5.1b0"],
"latest": "v0.5.1b0",
"main": true
}
```
/latest/ also resolves (HTTP 200) to the v0.5.1b0 content. The Pages deployments API now shows a fresh deployment record for this run at 2026-07-20T20:06:4x.

Recommendation: Close this issue — this was a transient GitHub Pages serving glitch (deploy recorded as successful but the edge cache/CDN didn't actually pick it up), not a reproducible workflow defect, and re-running the existing docs.yml workflow was sufficient to resolve it with no code changes. Worth reopening if the same staleness recurs after a future release tag, since GitHub-side Pages serving lag isn't something this repo's workflow can directly guard against — if it becomes a recurring pattern, a follow-up could add a post-deploy verification step (curl the live versions.json and compare to the artifact) so CI itself flags the mismatch instead of relying on manual audits.

Unrelated, FYI: local master in my working copy has an unpushed commit 644cce1 ("docs(readme): rewrite for accuracy...") that origin/master doesn't have yet (origin/master HEAD is still f126fb5, the 0.5.1b0 release commit). Not part of this issue's scope — flagging only in case the repo owner wants to push it themselves.