ci: pull upstream ecosystem-ref fixes (bokeh, jrnl-org) + fork-side Windows libclang exclude

[AdaWorldAPI]

Summary

Follow-up to the two non-required CI failures flagged (and left unfixed) while landing PRs #94/#96/#97/#98: the ecosystem job's project errors and the cargo test (windows-latest) crash. Investigated both against astral-sh/ruff upstream before touching anything, per this repo's own "measure before claiming a fix exists" discipline.

1. Two real upstream cherry-picks (clean, no conflicts)

The ecosystem job reported 5 project errors. Two of them are stale branch refs this repo inherited at fork time and upstream has since fixed:

• 67ffd19e — ruff-ecosystem: bump bokeh/bokeh branch to branch-3.10 (#26987) (was branch-3.3, deleted upstream)
• bd75eb1c — Update branch for jrnl (#27007) (was develop, renamed to main)

Confirmed via the exact CI log text on this fork (job 95614539452, PR run 32105673308):

Failed to clone bokeh/bokeh: fatal: Remote branch branch-3.3 not found in upstream origin
Failed to clone jrnl-org/jrnl: fatal: Remote branch develop not found in upstream origin

Cherry-picked verbatim (git cherry-pick), touching only python/ruff-ecosystem/ruff_ecosystem/defaults.py and scripts/check_ecosystem.py — no other files, no unrelated upstream drift pulled in.

The other 3 of the 5 ecosystem errors are NOT upstream-fixable and are intentionally left alone:

• rotki/rotki and indico/indico reference RUF105 in their own config, a rule that does not exist in this fork at all (git grep confirms zero hits; it exists upstream in noqa_comments.rs). Porting it is a real new-rule addition, not a ref bump.
• python-trio/trio references the selector builtin-argument-shadowing (the human-readable rule name, not its code A002). Upstream resolves that via a preview-gated "human-readable rule names" feature (is_human_readable_names_enabled, Rule::from_name, UnresolvedRuleSelector::resolve) that is entirely absent from this fork (git grep = zero hits).

Both are legitimate feature ports, not cherry-picks, and out of scope here — noted so they aren't silently dropped.

2. Fork-side fix: exclude ruff_cpp_spo from --all-features on Windows

This is NOT an upstream cherry-pick — ruff_cpp_spo is a fork-only crate (C++ SPO/transcode harvest arm) that doesn't exist upstream, so there is no upstream commit addressing it.

cargo-test-other's cargo nextest run --all-features --profile ci turns on ruff_cpp_spo's libclang feature on windows-latest too. The clang crate dlopens libclang at runtime there, and every libclang-backed test aborts with 0xc0000005 (Invalid access to memory location) instead of failing cleanly — confirmed via job 95617262943 on run 32106599591 (6 ABORTs, all under ruff_cpp_spo::clang_walker::* / libclang_tests::*). macos-latest runs the identical tests successfully.

Excludes ruff_cpp_spo from both the nextest run and the doctest run, Windows-only, rather than dropping --all-features workspace-wide or touching macOS.

Test plan

• git diff confirms only the two intended lines changed in the ecosystem-ref cherry-picks
• python3 -c "import yaml; yaml.safe_load(...)" — CI workflow YAML parses
• uvx prek run --from-ref origin/main --to-ref HEAD — all hooks pass except zizmor, which fails identically against the unmodified upstream origin/main copy of ci.yaml in this sandbox (403 from github.com/ghapi/advisories, no outbound GitHub API access here) — confirmed environmental, not caused by this diff
• CI on this PR (the actual falsifier — real GitHub Actions gets real libclang/network access this sandbox doesn't)

Kept as a separate branch, not merged into the drill-loop work landed in #94/#96/#97/#98.

---

Generated by Claude Code

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_42050244-41a4-423a-84b0-d581b98cc9d5)

[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, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.