bazel: model PyO3 and napi-rs cdylibs plus packaging handoff

[DecisionNerd]

Context

Implements step 6 of #1: model Python (PyO3) and Node (napi-rs) cdylibs plus ecosystem packaging handoff. This is existing Python/Node packaging — not Swift/Kotlin/UniFFI mobile bindings.

Work

• Build PyO3 and napi-rs cdylibs through Bazel.
• Preserve Python abi3, wheel metadata, clean-install, Arrow/PyArrow projection, and no-fallback assertions.
• Preserve Node target triples, addon naming, package assembly, smoke/parity tests, and npm provenance expectations.
• Allow maturin/napi tooling to assemble/sign/publish, but final-state release workflows must consume Bazel-built native artifacts rather than silently recompiling a different Rust graph.
• Keep PyPI/npm credentials and OIDC outside cacheable build actions.

Acceptance criteria

Given #9 API/library targets exist under Bazel
When PyO3 and napi-rs cdylibs plus packaging handoff land
Then Bazel-built Python wheels and Node packages can be assembled for CI smoke
And packaging steps do not silently recompile a different native implementation
And Swift/Kotlin/UniFFI work is not introduced

Out of scope

• Mobile bindings (Swift/Kotlin/UniFFI/XCFramework/JAR).
• Full cross-platform release parity matrix (bazel: cross-platform release targets and Cargo/Bazel parity evidence #6).
• CI Gate sole cutover (bazel: cut over CI Gate, retain rollback, retire Cargo sticky disks #4).

Evidence

• PR + ledger update; binding build/smoke on Blacksmith where classified; exact-head applicable CI green.
• Ordinary AGENTS.md close.

Relationships

• Parent / blocks: M2 gate: implement #1 Bazel migration via sub-agents #2
• Blocked by: bazel: model storage, execution, search, knowledge, and API libraries #9
• Blocks: bazel: cross-platform release targets and Cargo/Bazel parity evidence #6
• Canonical spec: build: migrate CI builds and tests to Bazel with Blacksmith caching #1 (Bindings and release artifacts; Implementation Sequence step 6)