[v2 Bug] dbt lint: ST09 (structure.join_condition_order) cannot be excluded, and --fix is a no-op for it

### Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

- [x] I believe this is a new bug in dbt v2.x
- [x] I have searched the existing issues and could not find a duplicate

### Current Behavior

`ST09` / `structure.join_condition_order` can't be excluded from `dbt lint` no matter how I ask it to be, and `--fix` doesn't touch it either. Tried:

- `.sqlfluff` config file: `exclude_rules = ..., structure.join_condition_order, ...`
- `--exclude-rules structure.join_condition_order`
- `--exclude-rules ST09`
- `--fix --rules ST09` (ran clean, zero diff - didn't fix anything)

All three exclude attempts still report `ST09` violations, and `--fix` is a silent no-op for it. As a sanity check I excluded a different rule the same three ways (`AL01` / `aliasing.table`) and that worked fine every time, so the exclude mechanism itself is fine - it's specific to this one rule.

### Expected Behavior

Excluding `ST09` (by name or code, config or CLI) should mean it doesn't show up in the output, same as every other rule.

### Steps To Reproduce

1. Have a project with a join where the referenced table isn't listed first (triggers `ST09`)
2. `dbt lint --exclude-rules ST09 ` (or the same via `.sqlfluff`'s `exclude_rules`)
3. `ST09` still shows up in the results

### Relevant log output

```shell
$ dbt lint --exclude-rules ST09 --format json models/some_model.sql
...
{"filepath": "models/some_model.sql", "violations": [
{"start_line_no": 40, "start_line_pos": 31, "code": "ST09", "description": "Joins should list the table referenced earlier first. [ST09].", "name": "structure.join_condition_order", "warning": false}
]}
```

Same thing happens with `exclude_rules = structure.join_condition_order` in `.sqlfluff` and with `--exclude-rules structure.join_condition_order`.

For comparison, excluding `AL01` (`aliasing.table`) the same way does work - it disappears from output as expected.

### Environment

- OS: macOS
- CPU: ARM
- dbt distribution and version: dbt-fusion 2.0.0-preview.186 (installed via the public.cdn.getdbt.com installer)

### Which database adapter are you using?

snowflake

### Is this a discrepancy vs. dbt 1.x?

- [x] Yes — this works in dbt 1.x but not in dbt v2.x

(sqlfluff itself, which is what we run today, respects the same exclusion fine)

### Additional Context

Ran into this doing a lint-parity check ahead of migrating a project from dbt Core + SQLFluff over to Fusion's `dbt lint`. We had this rule excluded on purpose (house style didn't enforce join-condition ordering), and it was tripping on plenty of real code - 75 actual violations across 29 files once I counted properly with sqlfluff (dbt lint's own count was ~198, but it counts each ANDed condition in a join separately instead of one per ON clause, so the raw numbers aren't comparable).

Ended up just fixing the 75 via `sqlfluff fix --rules ST09` instead of carrying the broken exclusion forward, so this isn't blocking us anymore, but figured the exclude/fix bug is worth flagging for anyone else with legitimate ST09 exceptions. Every other excluded rule in our config (9 of them) works fine via all the same mechanisms - this is the only one that doesn't.