ci: Include docs and /storybook site (github.io) step in Github release workflow

[awahab07]

Summary

Addresses the missing GitHub Pages publish step in the release workflow that left the hosted docs and Storybook stale after releases.

The hosted Elastic Charts docs and Storybook are now published as part of the release workflow so the public site stays aligned with released versions.

Details

This change moves stable GitHub Pages publishing into the manual release workflow instead of relying on the old main-branch Buildkite publish path.

It adds manual release inputs for dry runs and smoke-branch Pages testing, builds a release-ready static site artifact during the workflow, and publishes that assembled output to the configured Pages branch.

The docs and Storybook build logic is now shared through reusable TypeScript helpers under .buildkite/utils/site.ts, while .buildkite/scripts/build_release_site.ts remains the runnable entrypoint used by the GitHub release workflow.

The legacy Buildkite Deploy - GitHub Pages step is no longer the authoritative stable-site publisher, which prevents main-branch pushes from overwriting the release-driven public site.

How to test

1. Run yarn --cwd .buildkite build:release-site.
2. Verify .release-site/index.html and .release-site/storybook/index.html exist.
3. On the PR branch, run Publish a Release with dry_run=true, publish_pages=false, and pages_target_branch=gh-pages.
4. Download the release-site artifact and verify the assembled docs and Storybook output.
5. Optionally run the workflow again with dry_run=true, publish_pages=true, and pages_target_branch=gh-pages-smoke.
6. Inspect the gh-pages-smoke branch contents.
7. After merge, repeat the dry run on main.
8. When ready, run the workflow on main with dry_run=false, publish_pages=true, and pages_target_branch=gh-pages.

[awahab07]

buildkite test this

[elastic-datavis]

✅ Successful Deployment (build#247) - ed65a11

• Docs
• Storybook
• e2e server
• Playwright VRT report
• Playwright A11Y report

[nickofthyme]

The legacy Buildkite Deploy - GitHub Pages step is no longer the authoritative stable-site publisher, which prevents main-branch pushes from overwriting the release-driven public site.

I'm not sure this is the best approach. What about for changes to the docs alone where there is no fix or feature, that requires to run a release?

I can see pros and cons to both but I think having this on main that represents the current code is best.

@markov00 WDYT?