feat(release): embed the previous release tarball size in the doc data

[BryanFRD]

Closes #1045

embed-release-data.js now writes ferrflow_release_size_mb into docs/site/data/benchmarks.json, taken from the ferrflow-linux-x64.tar.gz asset of the latest published release (the one before the release in progress). The release step in CI gets GH_TOKEN so gh release view can read it. If gh fails or the asset is missing, the script logs it and leaves the file as is, so a release is never aborted by it.

Checked locally with a stubbed gh (value written, 3.4 for a 3.4 MB tarball) and a failing gh (file untouched). The repo has no JS test setup, so no test file was added.

Open question: should ferrflow_binary_size_mb stay as a fallback in the consumers (landing.component.ts / sync-docs.mjs)? That lives in FerrFlow-Cloud, so I did not touch it here. Auto-merge is off for that reason, and because the release job path can only be exercised on a real release.

[BryanFRD]

Question: should ferrflow_binary_size_mb stay as a consumer-side fallback in FerrFlow-Cloud (it is about 2.4x off), or should the page fail or omit the stat when ferrflow_release_size_mb is missing?

[ferrfleet-interne]

Nothing blocking. The size lookup is wrapped like the benchmark embed, so a failing gh call can't abort postBump mid-release. The string toFixed(1) value matches the existing *_size_mb fields. gh release view with no tag skips drafts, so the --draft release this run creates won't be picked up. Also, GH_TOKEN isn't one of the token variables ferrflow reads, so it won't override the bot token.