python: walking skeleton — workspace, two crates, importable wheel #1382

Created with Claude Code from the spec in #1341.

Parent

Sub-issue of #1341 (Python SDK tracer spec). Ticket 1 of 14.

What to build

A developer clones the repo, runs the Python workspace's build task, and import stackencrypt succeeds in a fresh virtualenv. stackencrypt.__engine__ reports the engine commit the extension was built from and stackencrypt.__version__ reports 0.1.0. Nothing encrypts yet; the extension exposes one trivial function the Python package calls to prove the two halves load together.

This is the fourth Cargo workspace (after the root, protect-ffi and EQL), under languages/python, with two crates: a core crate that holds the declaration plan and value conversion logic and depends on stack-encrypt by path, and an engine crate that is the _engine cdylib built with PyO3 0.29 and maturin. The pure-Python package stackencrypt wraps it. abi3-py39, Python 3.9 to 3.14. The extension-module feature is set only by maturin, so cargo test in the workspace links libpython and runs.

Acceptance criteria

• mise run python:build (or the equivalent named task) produces an importable stackencrypt in a virtualenv on the developer's machine with no credentials.
• stackencrypt.__engine__ and stackencrypt.__version__ are importable and correct.
• cargo test --locked in the Python workspace passes on a machine with Python installed; the task puts libpython on the loader path so the engine crate's tests link.
• A pure-Python pytest suite exists and runs (one smoke test calling the trivial engine function).
• The root Cargo.toml excludes the new workspace, and the three existing workspaces still build unchanged.
• The Cargo.lock of the new workspace is committed and cargo metadata --locked passes.
• No Linear IDs anywhere in the new files.