fix(bindings/python): support foyer wheels on armv7

[suyanhanx]

Which issue does this PR close?

Closes #7619.

Rationale for this change

Python release wheels currently build with services-all. foyer was removed
from that feature set in #7618 as a release mitigation because the armv7 wheel
jobs pulled in io-uring v0.7.12, whose prebuilt bindings intentionally reject
unsupported target architectures.

This PR implements the follow-up path that keeps foyer available in Python
release wheels without bypassing io-uring's native binding compatibility
check. Instead of using --cfg=io_uring_skip_arch_check, Python arm targets
enable io-uring's bindgen feature and generate target bindings during the
wheel build.

The manylinux and musllinux armv7 containers do not consistently provide kernel
UAPI headers new enough for io-uring v0.7.12, so the Python binding provides a
small local UAPI include file for bindgen. This keeps the generated bindings
stable across release runners while avoiding a vendored or patched io-uring
crate.

What changes are included in this PR?

• Add services-foyer back to Python services-all.
• Enable io-uring's bindgen feature only for Python target_arch = "arm" builds.
• Add a Python-binding-local BUILD_IO_URING_INCLUDE_FILE config and Linux UAPI header for io-uring bindgen.
• Regenerate Python service stubs so Scheme.Foyer and the Operator/AsyncOperator overloads are present again.
• Stabilize Python service generation by normalizing extra blank lines and preserving the trailing newline.

Are there any user-facing changes?

Yes. Python release wheels built with services-all include the foyer service
again, including armv7 wheels.

AI Usage Statement

I used OpenAI GPT-5 Codex in Codex to help implement, test, and validate this PR.

[Xuanwo]

I don't think this fix is correct.