TypedPython: compiled code calls Kotlin through the binder (embedded-runtime test) #45

What

A compiled function calls into Kotlin through the binder, from inside the embedded runtime on desktop. The test must show three things: it calls a Kotlin function exposed by the binder, it receives a Kotlin proxy and passes it back to Kotlin, and its results (including Kotlin-side effects) equal the interpreted run. The test lives in a ksp-fixtures module (desktopTest), not only in plain-CPython pytest.

Why

Maintainer requirement, relayed by the leader: compiled code must still talk to Kotlin freely. In the IR, binder functions and proxies are opaque objects (Global, GetAttr, CallObject; commit 6110e47). A function that calls Kotlin is impure, so its unbounded int values stay CPython int objects. Floats, bounded loop indices and the loops around the calls are still native.

A constraint to handle

The extension must be built against the CPython the app embeds (3.14.x from python-build-standalone, staged by the Gradle plugin), not the host's Python: headers, ABI tag and the free-threaded flavour must match. The test builds against the staged PYTHONHOME headers. If headers are missing from the staged tree, record that as a gap for M3 (pypackpack slot).

Done when

The ksp-fixtures desktopTest passes:

• interpreted and compiled results are equal;
• Kotlin-side call counts are equal;
• an exception thrown in Kotlin surfaces in the compiled caller with the same Python type and message as interpreted;
• no reference leaks across 10,000 calls.

The Kotlin direct C-ABI fast path (design §4.4) stays out of scope until the GIL decisions are made.