[Bug]: Proxy BVT can read stale lower_case_table_names on a new CN session

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

- [x] I have checked the existing issues.

### Branch Name

main / issue-26340-main

### Commit ID

a7a37c2519a90ff0bef22e2d7b9eda6dfbc07006 (PR #26462, base 47c8302f083b61c3b4a92a0ea539a28ef86d33c2)

### Other Environment Information

- Hardware parameters: GitHub Actions runner amd64-mo-shanghai-8c16g
- OS type: Linux
- Others: MatrixOne Compose CI, multi-CN Proxy BVT, run 31167719921, job 92832366914

### Actual Behavior

The Proxy BVT intermittently reads a stale session value after another connection changes an account-level global system variable.

In `test/distributed/cases/system_variable/lower_case_table_names.sql`, session 8 executes:

```sql
set global lower_case_table_names = 0;
```

A newly opened session 9 then executes:

```sql
select @@lower_case_table_names;
```

The expected value is `0`, but the Proxy BVT returned `1` at SQL rows 148 and 170. The same file passed all earlier global-value transitions in that run. The PR does not modify frontend system-variable handling or this BVT file.

### Expected Behavior

A new session on any CN should initialize its session variables from the latest committed account-level global variables. The BVT should consistently return `0` after the successful `SET GLOBAL`.

### Steps to Reproduce

1. Start the multi-CN compose cluster with Proxy.
2. Run `test/distributed/cases/system_variable/lower_case_table_names.sql` through mo-tester.
3. Repeat if necessary because Proxy routing makes the failure timing-dependent.
4. Observe that the new session can return `1` immediately after another connection committed `SET GLOBAL lower_case_table_names = 0`.

### Additional information

CI log:

```text
The value of [row:0,column:0] does not equal with each other,one is [0],but the other is [1]
[row:148][select @@lower_case_table_names;] was executed failed
EXPECT: 0
ACTUAL: 1

[row:170][select @@lower_case_table_names;] was executed failed
EXPECT: 0
ACTUAL: 1
```

The case previously had a manual `refresh_global_sys_vars_mgr` workaround, removed by PR #17273 when new sessions began reading the catalog directly. The current failure suggests a remaining cross-CN visibility or session initialization race.