Tracking Python wheel support for foyer on armv7

[Xuanwo]

Problem

During the v0.57.0-rc.1 release, Release Python Binding failed on the armv7 wheel job:

• RC tag: v0.57.0-rc.1
• Failed workflow: Release Python Binding
• Failed job: wheels (ubuntu-latest, armv7l)

The failing build used Python binding services-all, which included the foyer service at the time:

• bindings/python/Cargo.toml in v0.57.0-rc.1

foyer depends on the foyer crate:

• core/services/foyer/Cargo.toml in v0.57.0-rc.1

That dependency path pulls in io-uring v0.7.12. On armv7, io-uring rejects its prebuilt sys.rs bindings unless either bindgen is used or --cfg=io_uring_skip_arch_check is passed. The release log reported:

The prebuilt `sys.rs` may not be compatible with your target,
please use bindgen feature to generate new `sys.rs` of your arch
or use `--cfg=io_uring_skip_arch_check` to skip the check.

Release mitigation

For the 0.57.0 release, we should avoid bypassing io-uring's arch check. The release fix is to remove foyer from Python binding services-all instead of passing --cfg=io_uring_skip_arch_check.

Related PR:

• ci: fix release gate workflow failures #7618

Follow-up

We need to decide the long-term Python wheel policy for services that depend on platform-sensitive native Linux APIs.

Possible options:

1. Keep foyer out of Python services-all.
2. Add a separate opt-in Python feature for foyer.
3. Build Python wheels with different service sets per target.
4. Investigate enabling io-uring bindgen for affected targets, if the manylinux build environment can support it reliably.

The key requirement is that Python release wheels should not depend on bypassing native binding compatibility checks for unsupported architectures.