[fix](arrow-flight) Forward a statement to the master FE without touching the MySQL channel (#67569)

### What problem does this PR solve?

Related PR: #61050

Problem Summary:

**1. A Flight session could not forward a statement at all.**

An Arrow Flight SQL session has no `MysqlChannel`:
`FlightSqlConnectContext` overrides
`getMysqlChannel()` to throw `getMysqlChannel not in mysql connection`.
Since #61050,
`FEOpExecutor.buildStmtForwardParams()` reads the client's
`CLIENT_DEPRECATE_EOF` capability
straight off that channel, so on a multi-FE deployment every statement a
Flight connection has to
forward to the master fails with that message before the request is even
sent:

- any DDL issued over Arrow Flight SQL to a follower or observer FE;
- any statement at all when `force_forward_all_queries` is on.

`CLIENT_DEPRECATE_EOF` is a MySQL protocol capability, so only read it
for a MySQL connection. The
thrift field is `optional` with no IDL default, and leaving it unset for
other protocols puts the
master back on the packet layout it used before #61050 —
`ConnectProcessor` applies it only when
`isSetClientDeprecatedEOF() && isClientDeprecatedEOF()`, so unset is
equivalent to set-false for
every reader in every rolling-upgrade direction.

**2. Once the forward succeeds, nothing carries the master's answer back
to the Flight client.**

`ConnectProcessor.finalizeCommand()` is the only place a forwarded
statement's status and result set
are replayed, and it is MySQL-only: it opens with
`Preconditions.checkState(connectType.equals(ConnectType.MYSQL))`.
Nothing else reads
`getProxyStatusCode()` / `getShowResultSet()` / `getOutputPacket()`
except the audit log. So after
the RPC, `ctx.getState()` stays at the `OK` that `executeQuery()` set
with `reset()`, the
`FlightSqlChannel` stays empty, and `DorisFlightSqlProducer` answers
with `addOKResult()`'s
synthesized one-row `StatusResult = 0`. With a client connected over
Arrow Flight SQL to a follower
or observer:

- a DDL that **failed** on the master was reported to the client as
success — only the follower's
  audit event recorded the real error;
- a forwarded statement that returns rows (`SHOW FRONTENDS`, `SHOW
LOAD`, … — about 33
`ShowCommand` subclasses both forward and return rows) returned that
single `StatusResult` row
instead of the master's rows. The same statement run against the master
returns real rows, because
`StmtExecutor.sendResultSet()` already has a working Arrow Flight
branch.

This gap is older than #61050 (`finalizeCommand()` was already
MySQL-only before it), so fixing only
part 1 would have turned a loud, diagnosable error into a silent wrong
answer, which the
repository's "Error Means Failure" invariant does not allow. Part 2 is
therefore fixed here too:

- `ConnectProcessor.carryForwardedOutcomeToFlightSession()` is the Arrow
Flight counterpart of
`finalizeCommand()`'s forwarded-statement branch. It copies a non-zero
master status into
`ctx.getState()` (and logs it at WARN — the follower used to say
nothing), and otherwise replays
the master's result set through the existing `sendResultSet()` Arrow
Flight branch.
- It is called from the branch of `executeQuery()` that is **already**
scoped to
`ARROW_FLIGHT_SQL`, so it structurally cannot fire on a MySQL connection
and
  `finalizeCommand()`'s `getStateType() != ERR` condition is untouched.
- `StmtExecutor` now refuses to forward a *query* on an Arrow Flight SQL
connection, before the RPC.
A query result comes back as MySQL wire packets in
`TMasterOpResult.queryResultBufList`, which
only `finalizeCommand()` can replay and which cannot be converted to
Arrow batches; answering it
with a synthesized empty success would be the same silent wrong answer.
This is reachable only
under `force_forward_all_queries`, which `Config` documents as "For
testing purposes".

The MySQL path is byte-for-byte unchanged.