ci: move musl build to 8vcpu to tighten wall-clock band

[lemon07r]

Follow-up tuning to #49 based on the observed v1.0.1 timings and the 3.2x scaling measured on the 8vcpu Docker compile (172s vs 554s on 2vcpu).

musl on 4vcpu projected to ~6.5 min (compile ~302s scaling + ~90s fixed musl-tools setup), the clear outlier against arm/windows on 8vcpu (~4.3-4.5 min) and gnu on 4vcpu (~5.1 min). Moving musl to 8vcpu puts every target in a ~3-5 min band.

The sizing rationale with measured baselines is now a comment above the matrix so the next tuning pass has the data inline.

actionlint clean; label blacksmith-8vcpu-ubuntu-2404 smoke-verified earlier.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

---

Summary by cubic

Moves the musl release job from a 4‑vCPU to an 8‑vCPU runner to equalize CI wall‑clock time across targets. Previously musl took ~6.5 min on blacksmith-4vcpu-ubuntu-2404; now it should land ~4–5 min on blacksmith-8vcpu-ubuntu-2404, aligning with arm/windows and removing the slowest‑job gate.

Review notes

• Changes only the os for x86_64-unknown-linux-musl in .github/workflows/release.yml; build flags and artifacts are unchanged.
• Rationale and baseline timings (2→8 vCPU ~3.2× speedup) are documented in a comment above the matrix for future tuning.
• No rollout or migration required.

^{Written for commit db5dbab. Summary will update on new commits.}

[coderabbitai]

Warning

Review limit reached

@lemon07r, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 35 minutes

Limit details: You’ve used all 3 included reviews currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 56f9b1c6-69cb-4ca1-bc25-d596c964c56f

📥 Commits

Reviewing files that changed from the base of the PR and between ce2e297 and db5dbab.

📒 Files selected for processing (1)

• .github/workflows/release.yml

---

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Adjusts the release workflow’s runner sizing so the x86_64-unknown-linux-musl build runs on an 8‑vCPU Blacksmith runner, tightening overall release wall-clock time by reducing the slowest-job bottleneck.

Changes:

• Documented measured v1.0.1 baselines and the runner-sizing rationale inline above the build matrix.
• Moved the musl target from blacksmith-4vcpu-ubuntu-2404 to blacksmith-8vcpu-ubuntu-2404.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.