Fix docs-site deploy: install rpm2cpio in workflow + point canonical at live bao.builders

[d4551]

Summary

Ran the docs-site build → verify → bundle → FTPS publish pipeline end-to-end for the latest committed release set (v0.1.0) and fixed the two errors it surfaced. The site is now live and correct at https://bao.builders/.

What was run

• bun install (pinned bun@1.3.14)
• git lfs pull --include="packages/desktop/releases/**" — release binaries are Git LFS objects; pulled the real 641 MiB so the bundler doesn't fail-closed on 133-byte pointers
• bun run build:docs-site — Tailwind v4.3.3 + daisyUI 5.7.4 CSS + docs/releases/manifest.json (v0.1.0, 3 platforms, 8 files)
• bun run verify:desktop-releases — all artifacts, signatures, and checksums pass
• bun run docs-site:bundle — staged 7 page files + 8 release artifacts into dist/docs-site
• bun run docs-site:deploy — published 15 files / 641.0 MiB to pixie-ss1-ftp.porkbun.com/ (explicit FTPS)

Errors surfaced and fixed

1. deploy-docs-site.yml can't verify RPMs on the runner (CI bug)

verify:desktop-releases extracts every Linux package payload to confirm the bundled runtime contract, and RPM extraction shells out to rpm2cpio | cpio. desktop-release.yml installs cpio+rpm for its own verify step, but deploy-docs-site.yml (wired in #34) had no equivalent install step, and rpm2cpio is not preinstalled on ubuntu-24.04. Result: the deploy workflow fails at verification and never publishes.

Fix: add an "Install Linux release verification tools" step (cpio + rpm2cpio, the minimal set the verifier requires) before verify:desktop-releases. Idempotent if already present; mirrors the existing desktop-release.yml pattern. The verifier's hard-fail on a missing rpm2cpio is intentional (avoids rpm2cpio <missing> | cpio exiting 0 and false-passing), so the fix is to provision the tool, not weaken the check.

2. Deployed page canonical/og:url pointed at a dead domain (SEO/social bug)

The site is served from the FTP account bound to bao.builders (FTP user bao.builders), and baobuildbuddy.com returns NXDOMAIN (no DNS). Yet docs/index.html declared <link rel=canonical> and og:url as https://baobuildbuddy.com/, pointing search engines and social crawlers at a non-resolving domain. https://bao.builders/ is already the canonical public URL used throughout README.md and packages/desktop/releases/README.md.

Fix: set canonical and og:url to https://bao.builders/; update the deploy doc and the deploy script's header comment to match so the repo no longer references the dead apex. All other baobuildbuddy occurrences in index.html are correct GitHub repo links (github.com/d4551/baobuildbuddy) and were left untouched.

Live verification (after re-deploy)

curl https://bao.builders/
  <link rel="canonical" href="https://bao.builders/" />
  <meta property="og:url"   content="https://bao.builders/" />
curl https://bao.builders/releases/manifest.json
  "version": "0.1.0"   (generatedAt 2026-07-28T00:25:03Z)
curl -I https://bao.builders/releases/macos/BaoBuildBuddy_0.1.0_aarch64.dmg
  HTTP/2 200, content-length 67184004   (matches committed sha256.txt + sizes.json)

Notes

• The release binaries themselves were not rebuilt (they require native macOS/Windows/Linux-ARM hosts, code signing, and notarization — out of scope here). The committed v0.1.0 binaries in packages/desktop/releases/ are the latest verified builds; this PR only rebuilds the docs site from them and ships it.
• FTP credentials were used from the environment only and are not committed (the deploy script reads BAO_DOCS_FTP_HOST/USER/PASSWORD from env and refuses to run otherwise). The password was handled in this session; per docs/DOCS_SITE_DEPLOY.md it should be rotated at the host before being stored as a repository secret.
• git lfs pull left the release binaries smudged in the working tree (shown as modified by git status); their sha256 matches the committed LFS pointer oids, so they are not part of this PR — only the four code/doc files below are committed.