Make the dialect="duckdb" engage/decline outcome observable to the caller #237

dialect="duckdb" is an opt-in to a faster plan, but for a projection the IEJoin cannot rebuild the dialect silently emits the naive-predicate plan instead. The outcome is three-valued — engage, decline, raise — and a caller can only distinguish the first two by string-matching query(getvariable( in the returned SQL:

sql = giql.transpile(query, tables=[...], dialect="duckdb")
engaged = "query(getvariable(" in sql   # the only tell available today

For a caller whose reason to pass dialect="duckdb" is the IE_JOIN plan, "silently did the slower thing" is the one outcome they would want to know about, and it is the one the API hides. The performance guide enumerates the declining shapes, but the boundary is genuinely hard to predict from outside: it turns on which sqlglot node classes a SELECT-list expression contains and on whether DuckDB's generator round-trips the tree.

Raised as A11 in the round-1 review of #235 (.sdlc/reviews/issue-#109/review-1.md).

Suggested seam. A warnings.warn on decline, carrying the projection that caused it, leaving the filter policy to the caller — who can then error, log, or ignore it through the standard warnings machinery. That keeps the mechanism-over-policy preference the API guide states: the library reports what it did, the caller decides what that means. A structured return value or a require_fast_path=True kwarg are the alternatives, both larger and both changing the existing signature.

Ordering. #235 settled where the engage/decline boundary sits (a reject tuple grouped by property, plus a verified round-trip gate). This is worth doing on top of that rather than alongside it.