Allow mixing DataFrameSource and PinSource in multi-table sessions

Currently check_source_compatibility uses a class-identity check (type(new) is not type(first)) that blocks natural blends of source types. In practice, DataFrameSource and PinSource both materialize an eager frame at construction and could share a single DuckDBExecutor — the identity check is the only thing stopping it.

What to change

• Loosen check_source_compatibility to group by capability (can this source produce an eager frame for DuckDB registration?) rather than exact class identity
• Broaden DuckDBExecutor.__init__ to accept any source that satisfies this contract, not just DataFrameSource
• Update the routing in _build_query_executor accordingly

Out of scope

Remote-source coalescing (SQLAlchemy/Ibis into a shared DuckDB via snapshot or live ATTACH) is explicitly deferred — snapshot mode requires full table materialization at startup which doesn't scale, and live attach introduces SQL dialect drift, lockdown relaxation, and per-dialect connection-string translation. This issue covers local materializable sources only.

Context

Identified during review of #195.

Start with check_source_compatibility, DuckDBExecutor.init, and _build_query_executor to trace the current type-based routing. Update the compatibility contract for locally materializable sources, then verify that DataFrameSource and PinSource can share one executor while remote-source coalescing remains unchanged.