scx_cake: bump version + scx_cargo to fix crates.io install

[rrnewton]

Summary

Follow-up to #3583 / commits 97cf25f + 11cb5f2 that landed the symlink-based path fix for scx_cake (the same pattern scx_cosmos adopted in commit 605c7d2). That fix resolved the original

clang: error: no such file or directory: '../../../lib/arena.bpf.c'

blocking cargo install scx_cake from crates.io for 1.1.1. However, scx_cake 1.1.2 still cannot install from crates.io for a closely-related but distinct reason — surfaced only by cargo package -p scx_cake (verify step) end-to-end against the published deps:

src/bpf/lib/sdt_alloc.bpf.c:45:2: error: call to undeclared function 'scx_err_loc'

Why

Unlike scx_cosmos (which only bundles pmu.bpf.c), scx_cake bundles sdt_alloc.bpf.c and sdt_task.bpf.c — both of which now use the scx_err_loc / scx_err / scx_out_loc macros introduced in commit 73b4543 (lib: move allocators to BPF streams reporting, 2026-05-13). Those macros live in scheds/include/lib/alloc/bpf_helpers_local.h, which ships inside the scx_cargo crate's bpf_h tarball.

But the scx_cargo on crates.io is still 1.1.1 (published 2026-05-13, before the streams refactor). Its bundled bpf_helpers_local.h predates the macros, so any cake 1.1.2 install from crates.io against the published scx_cargo 1.1.1 fails clang at sdt_alloc.

Fix

Re-publish scx_cargo with the current (post-streams) bpf_h, and bump scx_cake to consume it:

• rust/scx_cargo: 1.1.1 → 1.1.2 (no code change — bpf_h is a symlink to ../../scheds/include, resolved at cargo package time, so the bump alone carries the updated bpf_helpers_local.h to crates.io)
• scheds/rust/scx_cake: 1.1.2 → 1.1.3, and bump build-dep scx_cargo "1.1.1" → "1.1.2"
• Cargo.lock updated to match

Release ordering

scx_cargo 1.1.2 must be published to crates.io before scx_cake 1.1.3 so cargo can resolve the new build-dep version.

Test plan

Local pre-publish simulation (the published scx_cargo 1.1.2 doesn't exist yet, so the standard cargo package --verify chicken-and-eggs — the workaround mirrors what cargo install will do post-publish):

• cargo build -p scx_cake clean (workspace path deps)

• cargo package -p scx_cargo -p scx_cake --no-verify produces both tarballs

• Extract both tarballs side-by-side under /tmp/cake-install-sim/:

  • scx_cargo-1.1.2/bpf_h/lib/alloc/bpf_helpers_local.h contains scx_err_loc ✓
  • scx_cake-1.1.3/src/bpf/lib/ contains all 8 lib .bpf.c files referenced by build.rs ✓

• In extracted scx_cake-1.1.3/, inject

  [workspace]
  
  [patch.crates-io]
  scx_cargo = { path = "../scx_cargo-1.1.2" }

  then cargo build — succeeds end-to-end. scx_err_loc resolves via the new bpf_h tar that scx_cargo 1.1.2 ships, and all add_source("src/bpf/lib/*.bpf.c") paths resolve inside the flat extracted tarball. This is the most faithful local simulation of cargo install scx_cake post-publish: the contents inside the extracted tarballs are exactly what the registry would serve.

• Reviewer / release engineer: publish scx_cargo 1.1.2 first, then scx_cake 1.1.3, then cargo install scx_cake from a clean toolchain to confirm crates.io install path.

[sirlucjan]

Thanks Ryan