Add experimental Python bindings for crossflow workflows

[ArizmendiWan]

This PR is an initial implementation for #189. It adds experimental Python bindings that allow a Python script to create a Crossflow executor, register Python callback nodes, inspect available metadata, and run JSON-defined workflows.

Current changes include:

• a new crossflow-python PyO3 package exposing an Executor API
• support for registering synchronous Python callback nodes with JSON-compatible request/config/response values
• workflow execution from Python using a JSON diagram and JSON-compatible request payloads
• Python-facing metadata access for the registered node/message catalog
• local development packaging via maturin and a small runnable example

GenAI Use

• I used a GenAI tool in this PR.
• I did not use GenAI
  Generated-by:
  OpenAI Codex Version 26.313.41514 (1043)

[mxgrey]

Thanks for working on this ticket, @ArizmendiWan.

I'm currently working on support for Python-script operations where the user puts Python code directly into their workflow diagram to be executed as node operations. There are handful of challenges that I'm still working out for this feature, including:

• Allowing Python-based operations to manipulate buffer values (this is critical to allow listeners and more complex behaviors to be written in Python). Based on my research so far, I believe this will require a lot of sensitive unsafe Rust code, so I'm going to be developing this very carefully.
• Allowing the scripts to be executed in different interpreter environments (e.g. local process, forked process, remote process) which is important to allow different scripts to have different dependencies. There are innumerable ways that users might want to have specially configured interpreter environments, so I plan on allowing a lot of customization in how users can define interpreter environments.

I think this PR will serve as a useful reference for how to make the diagram element registry accessible to Python, but I'd like to settle the above two points first. I expect to have that done in the next two weeks, or by the end of the month at worst. I think the outcome of those features will have a strong influence on this one, especially the buffer support for Python operations.

[ArizmendiWan]

Thanks for the context. That makes sense if buffer support and interpreter-environment design are still still being worked out. I’m happy to leave this PR up as reference material for now, or close it if you’d prefer to avoid overlap while that work is underway.