Architecture: Evaluate Rust/UniFFI for shared rendering logic (spike)

[sfloess]

Part of #233: Architecture: Unify curses-java and curses-themes with shared implementation

Scope

Time-boxed spike (1-2 days) to evaluate whether Rust + UniFFI is viable for sharing the ~125-line rendering engine (draw_box_3d(), shadow rendering) across Java and Python.

This was the #1 ranked solution from the multi-AI analysis (92% consensus, 3/3 models).

Tasks

• Set up minimal Rust crate with a single exported function (e.g., draw_box_3d)
• Compile to shared library (.so)
• Call from Java via FFM (same pattern as existing NcursesBridge.java)
• Call from Python via ctypes
• Evaluate: build complexity, binary size, developer experience
• Document findings and recommendation (go/no-go)

Decision Criteria

• Is the build pipeline manageable (Cargo + Maven + setuptools)?
• Does FFM calling work cleanly for the rendering API?
• Is the binary size acceptable?
• Is the Rust learning curve justified given ~125 lines of shared logic?

Deliverable

A written recommendation with go/no-go decision, posted as a comment on this issue and on the parent #233.

Note

If the spike determines Rust is not worthwhile, the JSON-only approach (accepting ~125 lines of duplicated rendering logic) is the agreed fallback. The rendering logic is small and stable, so duplication is acceptable if the complexity cost of Rust is too high.