[Feature] Native OSI parsing should pass the active adapter's dialect to OSIToMSIConverter (currently hardcoded ANSI_SQL)

### Describe the feature

dbt-core 1.12's native OSI parsing always instantiates the converter with its default dialect preference:

```python
# core/dbt/parser/osi.py
result = OSIToMSIConverter().convert(doc) # defaults to OSIDialect.ANSI_SQL
```

OSI expressions can carry multiple dialect variants of the same expression (`expression.dialects[]`), and the converter already supports a preferred-dialect parameter — but since dbt never passes one, projects on warehouse-specific SQL can't make dbt pick their dialect variant. With dbt-labs/metricflow#2094 / dbt-labs/metricflow#2095 adding `BIGQUERY` (and `MAQL`) to `OSIDialect`, the natural next step is for dbt to map the active adapter to a dialect preference (e.g. `bigquery` → `OSIDialect.BIGQUERY`, `snowflake` → `OSIDialect.SNOWFLAKE`, `databricks` → `OSIDialect.DATABRICKS`, fallback `ANSI_SQL`) and pass it to `OSIToMSIConverter`.

Today the fallback behavior (first available dialect when the preferred one is absent) keeps single-dialect documents working, so this is about making multi-dialect OSI documents resolve to the right variant per target warehouse.

### Who will this benefit?

Anyone running dbt's native OSI parsing on a non-ANSI warehouse and authoring OSI documents with per-dialect expressions — i.e. exactly the interoperability scenario OSI exists for. We hit this on BigQuery: all expressions must currently be authored under the `ANSI_SQL` dialect label even when the SQL is BigQuery-specific.

### Anything else?

Depends on the metricflow enum change (dbt-labs/metricflow#2094). Happy to contribute the mapping once that lands.