[v2 Bug] `dbt lint --fix` silently drops non-fixable violations from output without fixing or warning (e.g. dbt0115 / ST06)

## 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 (`dbt lint` is a Fusion-only command)
- [x] I have searched the existing issues and could not find a duplicate

## Current Behavior

`dbt lint --fix` succeeds silently on rules that are on the ["Rules without
autofix"](https://docs.getdbt.com/reference/commands/lint#rules-without-autofix)
list. Two things happen that together make the behaviour hard to discover:

1. The file is **not modified** — expected, since the rule can't be auto-fixed.
2. The violation is **removed from the `Errors and Warnings` output** of the
`--fix` invocation, and the summary reads `Finished 'lint' with N warnings`
with `N` one less than before.

The combined effect is that from the user's perspective the fix *appears* to
have succeeded. The only way to discover it hasn't is to re-run `dbt lint`
(without `--fix`), at which point the same warning reappears verbatim. There
is no output line like `1 violation not auto-fixable: ST06 (see docs)`.

I discovered this by trying to auto-fix `[warning] [WildcardBeforeSingleTargets
(dbt0115)]: Select wildcards then simple targets before calculations and
aggregates [ST06]` across a dbt project. `dbt lint --fix` kept telling me the
violation was gone, but subsequent `dbt lint` runs kept reporting it — I only
realised what was happening after diffing the file before and after.

## Expected Behavior

When `dbt lint --fix` encounters a violation for a rule that isn't on the
auto-fixable list, it should print an explicit "not fixed" line so the user
knows manual intervention is required. Something like:

```
=================== Errors and Warnings ====================
[warning] [WildcardBeforeSingleTargets (dbt0115)]: Not auto-fixable — reorder columns manually [ST06].
--> models/example/foo.sql:2:5
```

Ideally the exit status / summary would also count it (e.g.
`Finished 'lint --fix' with 1 warning (1 not auto-fixable)`) so that CI can
tell "clean" apart from "not fixed."

**Bonus feature request:** ST06 is listed as
[not auto-fixable](https://docs.getdbt.com/reference/commands/lint#rules-without-autofix)
because reordering column targets across Jinja template boundaries can't be
done safely via source-map. Upstream SQLFluff *does* auto-fix ST06 on the
rendered SQL. For SELECT lists that contain no Jinja between the targets that
need reordering, dbt lint could reasonably auto-fix ST06 too — either
unconditionally, or gated on "no Jinja in the SELECT list." Reordering ~90
violations across 75 files by hand was hours of mechanical work that a tool
should be able to do.

## Steps To Reproduce

Minimal repro (Snowflake project, dbt-fusion 2.0.0-preview.196):

Create `models/demo/demo.sql`:

```sql
with test as (
select
a,
round(b, 2) as c_calc,
d
from {{ source('foo', 'bar') }}
)
select * from test
```

1. `dbt lint models/demo/demo.sql`

→ reports:
```
[warning] [WildcardBeforeSingleTargets (dbt0115)]: Select wildcards then simple targets before calculations and aggregates [ST06].
--> models/demo/demo.sql:2:5
Finished 'lint' with 1 warning for target 'development' [5.3s]
```

2. `dbt lint --fix models/demo/demo.sql`

→ reports:
```
Finished 'lint' with 0 warnings for target 'development' [5.6s]
```
No mention of the ST06 warning. Success on the surface.

3. `diff` the file before and after step 2 → **byte-identical, no fix
applied**.

4. `dbt lint models/demo/demo.sql` again

→ the exact same ST06 warning reappears.

## Relevant log output

Full output from a demo run in my project:

```
$ dbt lint models/base/beehive/_st06_demo/_st06_demo.sql
dbt-fusion 2.0.0-preview.196
Loading ~/.dbt/profiles.yml
Started resolving packages from packages.yml
Finished [ 0.84s] resolving packages from packages.yml (7 items)
Started linting (1 items)
Linted [ 0.01s] models/base/beehive/_st06_demo/_st06_demo.sql
Finished [ 0.01s] linting (1 items)

=================== Errors and Warnings ====================
[warning] [WildcardBeforeSingleTargets (dbt0115)]: Select wildcards then simple targets before calculations and aggregates [ST06].
--> models/base/beehive/_st06_demo/_st06_demo.sql:2:5

==================== Execution Summary =====================
Finished 'lint' with 1 warning for target 'development' [5.3s]

$ dbt lint --fix models/base/beehive/_st06_demo/_st06_demo.sql
dbt-fusion 2.0.0-preview.196
...
==================== Execution Summary =====================
Finished 'lint' with 0 warnings for target 'development' [5.6s]

$ diff /tmp/before.sql models/base/beehive/_st06_demo/_st06_demo.sql
# (no output — files are identical)
```

## Environment

- OS: macOS 26.5 (Darwin 25F71)
- CPU: ARM (Apple Silicon)
- dbt distribution and version: `dbt-fusion 2.0.0-preview.196`
- SQLFluff (for cross-check): 3.4.2

## Which database adapter are you using?

- snowflake

## Additional notes

Cross-check against upstream SQLFluff 3.4.2 with the dbt templater on the same
file returns *no* ST06 violation — this suggests dbt-fusion's ST06
implementation is stricter than upstream's, which may be worth a separate
issue but is out of scope for this one. Happy to file that separately if
useful.