Expose SessionContext.register_variable / deregister_variable for SQL @var support

この issue では、PySessionContext、PyVarProvider の Rust ラッパー、および Python 向けの ABC が挙げられていますが、ファイルやテストはありません。まず、既存の PySessionContext バインディングと、upstream の SessionContext における register_variable および deregister_variable のシグネチャを追跡します。Python の呼び出し側が VarProvider を提供して登録および登録解除でき、GIL 境界を越えて安全にコールバックを受け取れるようになれば完了です。

Background

DataFusion's SessionContext exposes register_variable(var_type, provider) and deregister_variable(var_type) for plugging in a VarProvider that resolves SQL @var / @@var references at execution time. These were surfaced during a v54 upstream coverage audit but are not exposed in the Python bindings.

Upstream signature

pub fn register_variable(&self, var_type: VarType, provider: Arc<dyn VarProvider + Send + Sync>)
pub fn deregister_variable(&self, var_type: VarType) -> Option<Arc<dyn VarProvider + Send + Sync>>

VarProvider is a small trait with get_value(&self, name: Vec<String>) -> Result<ScalarValue> and get_type(&self, name: &[String]) -> Option<DataType>.

User value

Enables SQL like SELECT * FROM sales WHERE region = @current_region AND user_id = @user_id where the provider supplies per-query values. Useful for multi-tenant SaaS embedders, BI / notebook tools that want session-scoped parameters without f-string interpolation (no SQL injection risk), and tools porting MySQL / Postgres SQL that uses session variables.

Why deferred

Effort estimate is medium (~250-400 LOC): needs a PyVarProvider Rust wrapper that calls back into a user-supplied Python object across the GIL boundary, plus the register / deregister bindings on PySessionContext, plus a Python-facing ABC. No open user requests at the time of audit, so the work is currently speculative. Filed for tracking; revisit when a concrete user need surfaces or to complete the upstream surface area.