[Compatibility]: lc_time_names is writable but ignored by localized date functions

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

- [x] I have checked the existing issues, including open and closed issues.

### Branch Name

main

### Commit ID

fc621e3616d229c7a29d0c80e73ed8eb1997459c

### Other Environment Information

- MatrixOne: locally built from the commit above (`8.0.30-MatrixOne-v1.3.0`)
- MySQL baseline: 8.0.46
- Verification date: 2026-09-10

### Actual Behavior

MatrixOne exposes `lc_time_names` as a writable session/global variable, but changing it has no effect on localized date names. `DAYNAME`, `MONTHNAME`, and the locale-sensitive `%W`, `%M`, `%a`, `%b` `DATE_FORMAT` specifiers always return English text.

For the date `2026-09-10`:

```text
lc_time_names MatrixOne DAYNAME / MONTHNAME / DATE_FORMAT
fr_FR Thursday / September / Thursday September Thu Sep
de_DE Thursday / September / Thursday September Thu Sep
ja_JP Thursday / September / Thursday September Thu Sep
```

MySQL 8.0.46 returns:

```text
fr_FR jeudi / septembre / jeudi septembre jeu sep
de_DE Donnerstag / September / Donnerstag September Do Sep
ja_JP 木曜日 / 9月 / 木曜日 9月 木 9月
```

MatrixOne also starts with an empty-string `@@session.lc_time_names` rather than MySQL's `en_US`, and accepts arbitrary invalid locale names:

```sql
SET SESSION lc_time_names='not_a_locale';
SELECT @@session.lc_time_names;
-- MatrixOne accepts and returns not_a_locale.
```

MySQL rejects that assignment with error 1649 (`Unknown locale`) and preserves the previous valid setting.

This report uses direct expressions and DATE-column queries as the compatibility contract. MySQL itself has a prepared-statement nuance: constant or prepared `DAYNAME`/`MONTHNAME` results can retain the locale active at prepare time, while `DATE_FORMAT` observes the later setting. That separate MySQL behavior is not used to define this issue; MatrixOne's direct, non-prepared column results already ignore the variable.

### Expected Behavior

Valid `lc_time_names` values should control localized day/month names in `DAYNAME`, `MONTHNAME`, and the relevant `DATE_FORMAT` specifiers, matching MySQL. Unsupported locale identifiers should be rejected instead of being stored as inert arbitrary strings. The default should identify the active English locale rather than expose an empty value.

### Steps to Reproduce

```sql
DROP DATABASE IF EXISTS lc_time_names_repro;
CREATE DATABASE lc_time_names_repro;
USE lc_time_names_repro;

CREATE TABLE t(d DATE);
INSERT INTO t VALUES('2026-09-10');

SELECT @@session.lc_time_names;

SET SESSION lc_time_names='fr_FR';
SELECT @@session.lc_time_names;
SELECT DAYNAME(d),MONTHNAME(d),DATE_FORMAT(d,'%W %M %a %b') FROM t;

SET SESSION lc_time_names='de_DE';
SELECT DAYNAME(d),MONTHNAME(d),DATE_FORMAT(d,'%W %M %a %b') FROM t;

SET SESSION lc_time_names='ja_JP';
SELECT DAYNAME(d),MONTHNAME(d),DATE_FORMAT(d,'%W %M %a %b') FROM t;

SET SESSION lc_time_names='not_a_locale';
SELECT @@session.lc_time_names;
```

### Additional information

`pkg/frontend/variables.go` registers `lc_time_names` as an unrestricted string with an empty default. No production date-function code reads the variable. `func_binary.go` uses fixed English `WeekdayNames`, `MonthNames`, and abbreviation arrays for `DATE_FORMAT`; `DAYNAME` and `MONTHNAME` likewise have no session locale input.

Four valid locales, an invalid locale, literal and DATE-column expressions, all four localized `DATE_FORMAT` tokens, and three date-name functions were reproduced three times on the same latest-main build. No open or closed issue for `lc_time_names` was found.