dbt-state marks model as NO-OP despite SQL definition change (new column added)

## Problem

When a model's SQL definition is modified to add a new column, dbt-state marks the model as `NO-OP (within tolerance)` and skips the rebuild. This causes downstream models that reference the new column to fail with `invalid identifier` errors.

## Environment

- dbt-core: 1.12.0
- dbt-snowflake: 1.12.0
- dbt-state: 2.29.3
- Platform: Snowflake

## Steps to Reproduce

1. We have a model `model_a` that is modified in a feature branch to add a new column (`new_column`)
2. A downstream model `model_b` is also modified in the same branch to select this new column
3. CI clones the staging database (which does not yet have the new column) and runs `dbt run` with the modified models selected
4. dbt-state evaluates `model_a` and determines it is "within tolerance", marking it as `NO-OP (within tolerance)` — **the model is not rebuilt**
5. `model_b` runs next and fails because the column `new_column` does not exist in the unmodified table

## Expected Behavior

When the model's SQL definition has changed (specifically, new columns are added to the SELECT statement), dbt-state should detect this as a schema change and **always rebuild the model**, regardless of tolerance settings.

## Actual Behavior

```
3 of 52 START sql table model transformations.model_a [RUN]
3 of 52 OK created sql table model transformations.model_a [NO-OP (within tolerance) in 4.75s]
5 of 52 START sql table model datamarts.model_b [RUN]
5 of 52 ERROR creating sql table model datamarts.model_b [ERROR in 0.93s]

Database Error: SQL compilation error: error line 78 at position 4
invalid identifier 'NEW_COLUMN'
```

## Impact

This breaks CI pipelines for any branch that adds new columns to existing models. The only workaround currently is to disable dbt-state entirely for the affected models, which defeats the purpose of the optimization.

## Questions

- Is there a configuration option to make dbt-state always rebuild when the compiled SQL has changed (not just data tolerance)?
- Should schema-level changes (new/removed columns) bypass the tolerance check entirely?