Follow upstream to BootAgent v0.6.0

[yujiezhang-ops]

Upstream renamed itself and published v0.6.0, which unblocked everything the
rename plan was holding. These land together because they are coupled by that
release: switching the feed without the asset fix would publish a download page
offering Windows an OTA update payload.

Closes #28.

The download page was about to get worse

v0.6.0 changed the shape of the asset set, not just the prefix. It ships native
installers instead of archives, Linux for the first time, and ota-* update
payloads beside the installers. Against the old matcher that produced:

platform	offered before this PR	offered now
macOS	BootAgent-darwin-*.dmg	same
Windows	ota-BootAgent-windows-*.zip	BootAgent-windows-*-installer.exe
Linux	BootAgent-linux-amd64.AppImage	plus linux-arm64

The Windows column is the problem: the real installers are -installer.exe, and
the pattern anchored the arch to the extension, so they never matched. The OTA
payload satisfied every other rule — platform, arch, .zip — so it won by
default. An update payload is not a first install.

Four changes, each with a test that fails without it:

• Exclude ota-* by name.
• Accept a trailing word after the arch, so -installer.exe is seen.
• Choose among formats by a stated preference (native installer first, archive
  last) rather than by feed order, and emit one target per platform-arch since
  callers resolve with .find(). macOS was picking .dmg over .zip on
  alphabetical luck; renaming an asset so the archive sorted first would have
  silently switched every macOS visitor to a zip. One of the new tests reverses the
  feed and asserts the answer does not change — that is the assertion that would
  have caught this originally.
• Add linux-arm64, which upstream now builds. Without an entry the asset was
  matched and then discarded, hiding a build that exists.

~/.oneagent/ → ~/.bootagent/

The released binary now creates the new path, so the docs can name it. All ten
sites updated, including the aider --env-file command a reader pastes into a
shell.

06-upgrade.md gains what the migration actually does, in both locales. This is
not a one-line reassurance — read from upstream's internal/app/migration.go:

• copies the old directory except runtimes/;
• rewrites the provider entry naming the old product in six agents' own configs;
• retains the original as ~/.oneagent-migrated-<timestamp> for the user to delete.

So managed Node, uv and installed agents have to be reinstalled. Configuration
survives; executables do not. A reader who is not told that will think the upgrade
was lossless and then find their agents missing.

Catalog refresh surfaced two latent bugs

Re-copied from the v0.6.0 tag per data/README.md rather than hand-edited, which
is how bootagent_version and aider's config_path arrive correctly instead of
being guessed. Brings kimi-code, plus DeepSeek and Moonshot as providers — 47
pages to 50.

Moonshot introduced two protocol statuses the site had never seen, and both broke
something that was correct for the values that existed when it was written:

• route-present-unverified had no label and fell through to the unsupported
  verdict, which would have printed 不支持 against a provider that publishes the
  route — a stronger claim than the data supports, and exactly the distinction
  release-candidate-required is already carved out to avoid.
• The provider page's status note was a ternary whose else branch asserted the
  protocol was implemented. False the moment not-supported arrived. Keyed by
  status now.

A decayed e2e assertion, removed rather than repointed

site.spec.ts asserted the "this platform is not published yet" state, first
against windows-x64 and then against linux-x64. Both decayed the same way:
upstream shipped the platform and the test was left checking that a working
download was absent. Every target now has an asset, so the state is unreachable
from the live feed. release-channel.test.ts already covers it against a stubbed
feed, which does not depend on what upstream happens to ship.

Verification

100 unit tests, 50 pages through astro check and validate-build.mjs, 213 e2e
with an authenticated feed.

Four visual baselines regenerated for the migrated path on the review screen.
Checked per-pixel rather than trusting the tolerance: 239 pixels of text at
y=438-448 and 9 at the window corner, no layout shift. Worth knowing that these
baselines do not fail on small text changes — the delta fits under
maxDiffPixels, which is sized for the window edge.

Also export GITHUB_TOKEN="$(gh auth token)" before running e2e locally, or the
download-page tests skip once the rate limit is spent and the run reports a green
198 instead of 213.

Not in this PR

• bootagent.ai does not serve the site. Pages is configured for it but its
  DNS resolves to a registrar parking page rather than GitHub Pages; the old domain
  404s because Pages no longer claims it, and the github.io URL 301-redirects to
  the parking page. There is currently no working URL. Needs DNS access this
  repository does not have.
• The artwork is still the pre-rename drawing, and the macOS screenshots still show
  dialogs naming the old product.