[Compatibility]: WEEK again ignores nonzero default_week_format session values

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

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

This behavior was previously reported in #24293 and fixed by #24302, but the fix is no longer present on current `main`. Because #24293 is closed, this report tracks the current regression rather than reopening it.

### 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

`WEEK(date)` and `WEEK(datetime)` ignore every nonzero `@@session.default_week_format` value and always calculate using mode 0.

The variable accepts values 0 through 7 and reads them back correctly, and the explicit two-argument `WEEK(value, mode)` form produces the correct result for all eight modes. Only the one-argument form fails to consume session state.

For example:

```sql
SET SESSION default_week_format=1;
SELECT @@session.default_week_format;
-- 1

SELECT WEEK(DATE '2026-05-07'), WEEK(DATE '2026-05-07',1);
-- MatrixOne: 18, 19
-- MySQL: 19, 19

SET SESSION default_week_format=7;
SELECT WEEK(DATE '2026-01-01'), WEEK(DATE '2026-01-01',7);
-- MatrixOne: 0, 52
-- MySQL: 52, 52
```

The same result occurs for DATE columns, DATETIME columns, literal/string input, and a prepared statement executed after changing the session variable. A prepared one-argument `WEEK` statement continues to return mode-0 results under modes 1, 3, and 7.

`WEEKOFYEAR(date)` remains equivalent to explicit mode 3 and `YEARWEEK(date)` retains its fixed default-mode behavior; those controls are not affected.

### Expected Behavior

Per MySQL's `WEEK()` contract, when the mode argument is omitted, the function should use the current session's `default_week_format` value. Direct and prepared execution should match `WEEK(value, @@session.default_week_format)` for all modes 0 through 7.

### Steps to Reproduce

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

CREATE TABLE t(d DATE, dt DATETIME);
INSERT INTO t VALUES
('2026-01-01','2026-01-01 12:34:56'),
('2026-05-07','2026-05-07 12:34:56');

PREPARE s FROM
'SELECT d,WEEK(d),WEEK(dt) FROM t ORDER BY d';

SET SESSION default_week_format=1;
SELECT @@session.default_week_format;
SELECT d,WEEK(d),WEEK(dt),WEEK(d,1),WEEK(dt,1)
FROM t ORDER BY d;
EXECUTE s;

SET SESSION default_week_format=3;
SELECT d,WEEK(d),WEEK(dt),WEEK(d,3),WEEK(dt,3)
FROM t ORDER BY d;
EXECUTE s;

SET SESSION default_week_format=7;
SELECT d,WEEK(d),WEEK(dt),WEEK(d,7),WEEK(dt,7)
FROM t ORDER BY d;
EXECUTE s;

DEALLOCATE PREPARE s;
```

### Additional information

The original fix in #24302 added a `getDefaultWeekFormatMode(proc)` lookup through `Process.GetResolveVariableFunc()` and marked the one-argument overload as session-sensitive. Current `pkg/sql/plan/function/func_unary.go` no longer contains that lookup: `DateToWeek` and `DatetimeToWeek` initialize `mode := 0` and change it only when a second argument exists. The current `WEEK` overload registration also has no session-sensitive flag.

Modes 0 through 7, five year/week boundary dates, DATE/DATETIME/literal paths, explicit-mode controls, WEEKOFYEAR/YEARWEEK controls, and prepared execution after session changes were reproduced three times on the same latest-main build. MySQL 8.0.46 changes the one-argument result with every applicable `default_week_format` mode.