[FEATURE] Defensive: OData push-down $select should always be a superset of $filter/$orderby columns

[jeffreyaven]

Summary

Belt-and-suspenders hardening: when translating a PushdownIntent to OData query
options, ensure the emitted $select is a superset of the columns used in
$filter and $orderby, so any-sdk never produces a request that projects away a
column it is simultaneously filtering or ordering on.

Context

Primary fix is in stackql - see stackql#682 (buildPushdownIntent folds
WHERE/ORDER BY columns into the projection). This issue is the complementary guard
so a future caller, or a different front end reusing any-sdk, cannot reintroduce the
same footgun. Lower priority; redundant once stackql#682 lands.

Where

internal/anysdk/query_param_pushdown_apply.go, applyPushdownSelect (invoked from
ApplyPushdown). No new plumbing is required — the data is already on the intent:
intent.GetPredicates() (each GetColumn()) and intent.GetOrderBy() (GetColumn()).

Fix sketch

When emitting a $select (non-empty projection), extend the projected set with the
filter and order-by column names before joining, subject to the select
supportedColumns allowlist:

- add filter/orderby columns to the $select set
- if a filter/orderby column is NOT in select.supportedColumns, do not add it
  (preserve the existing all-or-nothing $select semantics rather than emit an
  incoherent $select)
- when the projection is empty (SELECT *), continue to emit no $select

Note

Purely additive coherence — it must not change behavior for queries that already
project their filter/order-by columns. Cross-link with stackql#682.