feat: add pybind11 package

[tz12323]

Adds compat.pybind11 and a consumer example resolved from this checkout.

The follow-up review fixes descriptor identity/layout and validates actual library behavior. Source URLs are pinned and hashed; plain-string GLOBAL URLs retain the documented CN fallback. See .agents/docs/2026-10-13-add-pybind11-plan.md for build shape, feature assessment and validation.

The pinned upstream revision is a 3.2.0 development snapshot, indexed as 3.2.0-dev.6254086. The example uses the declared xim:python@3.13.12 SDK and checks Python evaluation and C++ callbacks.

[tz12323]

[CI][linux-llvm] pybind11 embed test fails: dual libc conflict

Observation

On linux-llvm CI, mcpp test -p pybind11 fails at the embed test.

rule B: artifact ... resolves libc from /usr/lib/x86_64-linux-gnu/libc.so.6
while RuntimeBinding glibc@2.44.3 selects /home/runner/.mcpp/registry/data/xpkgs/xim-x-glibc/2.44.3/lib;
one process cannot have two libcs.
Fix: rebuild after selecting a compatible SubOS in mcpp.toml ([xlings] subos = "<name>").

Root cause

The embed example links against host Python interpreter.
Host Python binary depends on the system glibc (/usr/lib/x86_64-linux-gnu/libc.so.6).
Meanwhile the mcpp build graph pulls in the standalone xim packaged glibc@2.44.3.
A single ELF process cannot load two distinct glibc implementations, triggering the mcpp runtime binding check failure at build time.

[Sunrisepeak]

Reviewed canonical compat.pybind11 identity, the honest 3.2.0 development-snapshot version and the pinned archive/hash. The example declares one Python SDK and uses matching headers, import library/runtime and standard library; it evaluates Python and calls C++ from Python. No guessed Python ABI macros or duplicate DLL staging remain. The CI-pinned local embedding test passes and every current CI check passes (conditional reporting jobs are skipped). No unresolved review findings.

[tz12323]

Regarding this PR:

I would like to raise a feature expectation for pybind11 integration here.
Currently it is tied to the Python interpreter bundled inside xlings, which limits which Python versions we can target.

I hope pybind11 can work with system‑provided / user‑selected Python interpreters, supporting multiple Python versions flexibly.
We want the similar flexibility that Rust’s pyo3 + maturin brings:

• Build against different user Python versions
• Support abi3 / multiple Python ABI
• Avoid being locked into one single bundled Python copy from xlings

Binding to xlings‑bundled Python reduces real‑world usability, as users often use different Python versions (system python, venv, conda, uv-managed python etc).
Could we consider decoupling from xlings internal Python and let pybind11 discover & build against target Python interpreter on host?