Bump whitaker-installer to 0.2.6

[leynos]

Summary

Bumps WHITAKER_INSTALLER_VERSION from 0.2.5 to 0.2.6 in ci.yml.

Review walkthrough

One-line env change. The 0.2.5 installer builds dylint_driver 4.1.0, which fails to compile on the current nightly (E0609 env_depinfo), breaking the lint step on every run — the same pre-existing drift already fixed in monotony, chutoro, and tei-rapporteur.

Validation

CI on this pull request exercises the lint step with the new installer.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[sourcery-ai]

Sorry @leynos, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 45 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

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 for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4ad57acc-1c7c-4016-84cf-87a4a1df69de

📥 Commits

Reviewing files that changed from the base of the PR and between 1a46d13 and 90e084e.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bump-whitaker-installer

---

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

[leynos]

Superseded by #147, already merged to main.

Root cause of the build-test failure on this branch's last run (29751909918 /
job 88384320910): the "Install Whitaker" step's fallback guard,
if cargo binstall --version >/dev/null 2>&1, is broken — cargo-binstall
treats a bare --version as the crate-version selector option, which needs
a value, so it exits non-zero even when cargo-binstall is present and
working (it had just installed cargo-audit two steps earlier via
cargo binstall --no-confirm cargo-audit). The guard should read
cargo binstall -V. Because the guard always reports "unavailable", the
step always falls through to cargo install --locked whitaker-installer --version "$WHITAKER_INSTALLER_VERSION", a from-source build against
whitaker-installer's own published lockfile.

That fallback is what actually broke this PR: whitaker-installer 0.2.6's own
lockfile pulls in cargo-platform 0.3.3, which requires rustc >= 1.91, but
podbot's rust-toolchain.toml pins channel "1.88". main has since jumped
straight to 0.2.7 (#147), whose lockfile does not hit that MSRV wall on
1.88 — the same broken binstall guard fires there too (confirmed in run
29966773613), but the source build succeeds. Bumping this branch to 0.2.7
would just reproduce #147's diff with no net change, so closing this in
favour of it rather than force-pushing an empty rebase.

The cargo binstall -V guard fix is worth a follow-up so the fallback stops
firing needlessly, but it does not block CI today.