feat(auth): authorize query-auth reads and carry the grant on the split

[plusplusjiajia]

Purpose

A query-auth.enabled table makes the server return a per-user row filter and column masking that the client is expected to apply. This client cannot apply them yet, so it refuses to read such a table at all — even for a user the server reports as unrestricted. This slice fetches the authorization at scan-plan time and carries it to the read, so that user can read. A user with rules gets the same refusal as before.

Brief change log

TableScan::plan authorizes once and stamps the result on every split, as Java wraps each split in a QueryAuthSplit. TableRead::to_arrow then decides from the splits: each must carry a grant, from this handle,
and unrestricted — per split, since split lists can be concatenated across plans.

Whether a table is query-auth comes from the server, not the loaded handle: the option can be set after a load, and a cached false would skip authorization entirely. Sync read boundaries cannot ask, so they
read a marker the splits carry. Unlike the grant it survives serialization, so a round-tripped split still demands authorization and, having lost the grant, fails closed.

Four refusals are deliberate. A restricted grant fails at planning, since a plan carries row counts and min/max that engines answer COUNT/MIN/MAX from without reading a row. A time-travelled, branch, or
decorated (db.t$branch_x, db.t$files) handle is refused, since the server rules on the current schema while those read other files. A plan is refused when a data file still carries statistics for a column the
current schema no longer has — value_stats and write_cols are public on every split. And the request names no columns, which the server expands to the real schema fields — Java sends the read type's names
instead. Naming a reserved system column would fail the server's permission check and deny an otherwise authorized user, so a read that reaches one is refused client-side instead; the cost is that a user
authorized for only a subset of columns is still refused, as today.

AuthTableQueryResponse rejects unknown fields, unlike every other response: an absent field reads as "no rule", so protocol drift would look like an unrestricted grant.