[Feature Request]: functional dependency exception of group by

### Is there an existing issue for the same feature request?

- [x] I have checked the existing issues.

### Is your feature request related to a problem?

```Markdown
# GROUP BY rejects columns functionally dependent on the
# grouped primary key (MySQL-compatibility gap)

## Summary

MatrixOne rejects `SELECT` queries that name a
non-aggregated column when only the table's primary key
is listed in `GROUP BY`, even though every other selected
column from that table is uniquely determined by that
primary key. Standard SQL (SQL:1999 and later) and MySQL
itself (`ONLY_FULL_GROUP_BY`, the default mode since 5.7.5)
both permit this via the "functional dependency" exception.
Since MatrixOne advertises MySQL wire and SQL compatibility,
this is a compatibility gap, not merely a stricter default.

## Environment

- Product: MatrixOne Cloud (free tier), cluster region
cn-hangzhou
- Client: Python, `pymysql` driver, MySQL wire protocol
- Server version: unknown -- please attach the output of
`SELECT VERSION();` from the same cluster when filing

## Schema (minimal reproduction)

CREATE TABLE job (
job_id BIGINT AUTO_INCREMENT PRIMARY KEY,
source VARCHAR(255),
owner_id BIGINT
);

CREATE TABLE cv (
cv_id BIGINT AUTO_INCREMENT PRIMARY KEY,
job_id BIGINT
);

CREATE TABLE app_user (
user_id BIGINT AUTO_INCREMENT PRIMARY KEY,
full_name VARCHAR(255)
);

## Query

SELECT job.job_id, job.source, COUNT(cv.cv_id),
job.owner_id, owner.full_name
FROM job LEFT JOIN cv USING (job_id)
LEFT JOIN app_user owner
ON owner.user_id = job.owner_id
GROUP BY job.job_id, job.owner_id, owner.full_name;

## Expected behavior

The query should succeed. `job.job_id` is the primary key
of `job` and is present in `GROUP BY`, so `job.source` is
functionally dependent on it (at most one value of
`job.source` per group) and does not need to be listed
separately. `owner.full_name` is already explicit in the
`GROUP BY` list.

Real MySQL (5.7.5+, default `sql_mode` including
`ONLY_FULL_GROUP_BY`) and PostgreSQL (9.1+) both accept
this query for exactly this reason.

## Actual behavior

MatrixOne rejects the query with:

column "job.source" must appear in the GROUP BY clause
or be used in an aggregate function

This suggests MatrixOne enforces the older, strict SQL-92
rule (every non-aggregated selected column must appear
literally in `GROUP BY`) without the primary-key
functional-dependency exception that later SQL standards,
and MySQL itself, define.

## Impact

Applications ported from MySQL that rely on grouping by a
single-table primary key and selecting other columns from
that same table -- a very common, standards-legal pattern --
fail against MatrixOne and must be rewritten to spell out
every non-aggregated column in `GROUP BY`, even though doing
so changes nothing about the result.

## Workaround

List every non-aggregated selected column explicitly in
`GROUP BY`. Since the extra columns are already functionally
determined by the primary key, this changes no query
results -- it just satisfies MatrixOne's stricter check:

GROUP BY job.job_id, job.source, job.owner_id,
owner.full_name

## Ask

Please confirm whether MatrixOne intends to support the
SQL:1999 / MySQL `ONLY_FULL_GROUP_BY` functional-dependency
exception for primary-key grouping, and if so, treat this as
a bug; if not, please document the divergence from MySQL
compatibility so callers know to always fully enumerate
`GROUP BY` columns.
```

### Describe the feature you'd like

Implement this feature, as it is SQL 99 standard.

### Describe implementation you've considered

_No response_

### Documentation, Adoption, Use Case, Migration Strategy

```Markdown

```

### Additional information

_No response_