[Bug]: CALL / stored procedure raises misleading "unclassified statement appears in uncommitted transaction" internal error

### Is there an existing issue for the same bug?

- [X] I have checked the existing issues.

### Branch Name

v4.0.0-rc3

### Commit ID

8.0.30-MatrixOne-v4.0.0-rc3

### Other Environment Information

- Hardware parameters: N/A
- OS type: N/A
- Others: Found by the JDBC 4.2 API conformance probe (driver-level `java.sql.*` surface, `JDBC_COMPAT.md`), reduced to a driver-independent SQL repro. MySQL 8.0.30 wire protocol.

### Actual Behavior

Stored procedures are not supported. However, MatrixOne reports it via a confusing internal error rather than a clean "feature not supported":

```sql
CREATE PROCEDURE p1() BEGIN SELECT 1; END; -- accepted
CALL p1();
-- MatrixOne: internal error: unclassified statement appears in uncommitted transaction
```

### Expected Behavior

A clear `not supported: stored procedures`-style error (ideally with a MySQL-compatible error code) — or, alternatively, implement `CREATE PROCEDURE` / `CALL`.

### Steps to Reproduce

```sql
CREATE PROCEDURE p1() BEGIN SELECT 1; END;
CALL p1(); -- observed: internal error: unclassified statement appears in uncommitted transaction
```

### Additional information

**Impact:** minor, but the `internal error` / "unclassified statement" wording misleads users (and JDBC `CallableStatement.execute()` callers) into thinking it is a transaction-state problem rather than an unimplemented feature.

**Related:** the same generic "unclassified statement appears in uncommitted transaction" error is raised for several other unsupported statements — e.g. #24544 (`DATA BRANCH MERGE/PICK`), #23129 (`LOCK TABLES`, closed), #9594 (`DECLARE`/`DO`, closed) — which suggests a single catch-all error path that should instead return a clear, per-statement "not supported" message.

**Background:** dengn/php-tester JDBC 4.2 API conformance probe (`JDBC_COMPAT.md`).