fix(docs): serve the latest released documentation on Pages

[taco3064]

The official site showed development documentation after 4.1.0 was published. Build public Pages from GitHub's latest stable release tag and show that version (currently v4.1.0), so the documentation and generated API describe the released product.

The existing Docs workflow checks out the released source separately from publishing tools. Only the two badge presentation files are overlaid to support the existing 4.1.0 tag; guides, API source, dependencies, and build configuration come from the tag. Reject draft/prerelease metadata and package/tag mismatches. Recheck the latest release before deployment.

Successful Release (tag) workflow completion triggers documentation deployment, covering both normal and recovery publication. This uses workflow_run because releases created with GITHUB_TOKEN do not trigger another release-event workflow. Main pushes and manual runs redeploy the latest release; local builds without release metadata retain their development identity. No additional workflow, npm release, or field validation is introduced.

This implements the owner's explicit correction to #516/#544: the official website must represent the released product.

Validation:

• Six version identity tests pass, including both locales and version mismatch rejection.
• Nine execution controls for the workflow's actual release-selection and package-validation code pass.
• actionlint and lint-staged pass.
• Clean detached v4.1.0 (90d2a27) install and docs build/check pass: 546 internal links and both public API entry points verified.
• Inspected rendered English/Chinese home and configuration pages: every badge reads v4.1.0.
• Independent acceptance: base 3286258, tree 5012742923819ac976aec42b9453b415fcd2977e.

After merge, the main push deploys the released 4.1.0 documentation automatically.