Spurious CustomKeyInConfigDeprecation on non-supported adapters: init_config never calls uses_adapter

### Expected behavior

The extension should match dbt's CLI: adapter-specific config validation (the jsonschema check behind `CustomKeyInConfigDeprecation`) should run only for the adapters dbt actually supports it on - bigquery, databricks, redshift, snowflake. On any other adapter (e.g. Exasol), the extension should not flag valid adapter-specific config keys.

Concretely: a project that parses cleanly with `dbt parse` / `dbt build` from the CLI should also parse cleanly in the extension, with no `CustomKeyInConfigDeprecation` warning for a config key the adapter declares as first-class (e.g. dbt-exasol's `distribute_by_config`).

### Actual behavior

The extension emits a `CustomKeyInConfigDeprecation` warning for a valid adapter-specific config key that dbt's own CLI does not flag on the same project. Example: dbt-exasol declares `distribute_by_config` as a first-class config (read via `config.get(...)`), yet the extension reports it as an unknown/custom config key. Running `dbt parse` or `dbt build` from the CLI on the identical project produces no such warning.

**Root cause:** dbt gates this validation on the invocation context's adapter set:

```python
# dbt/jsonschemas/jsonschemas.py
_JSONSCHEMA_SUPPORTED_ADAPTERS = {"bigquery", "databricks", "redshift", "snowflake"}

def _can_run_validations() -> bool:
return get_invocation_context().adapter_types.issubset(_JSONSCHEMA_SUPPORTED_ADAPTERS)
```

dbt's CLI populates that set before parsing (`dbt/cli/requires.py`): `get_invocation_context().uses_adapter(profile.credentials.type)`.

The extension parses via `DbtProject.init_config()` -> `ManifestLoader().load()` in `@altimateai/dbt-integration`'s `dbt_core_integration.py` and never calls `uses_adapter`. So `adapter_types` stays an empty set, and `set().issubset(anything)` is vacuously `True`. `_can_run_validations()` therefore returns `True` for every adapter — including unsupported ones — causing the validator to run against adapters it was never meant to, and flagging their valid config keys.

Net effect: the warning fires on all non-supported adapters, not just Exasol.

### Steps To Reproduce

1. Open a dbt project that uses a non-supported adapter — anything other than bigquery / databricks / redshift / snowflake (reproduced with dbt-exasol 1.10.6 on dbt-core 1.11.x).
2. Add a valid adapter-specific config to a model, e.g.:
```
{{ config(materialized='incremental', distribute_by_config=['id']) }}
```
(`distribute_by_config` is a first-class config declared by the dbt-exasol adapter.)
3. Let the dbt Power User extension parse the project (open the model / trigger a parse).
4. Observe: the extension reports `CustomKeyInConfigDeprecation` for `distribute_by_config`.
5. Run `dbt parse` (or `dbt build`) from the CLI on the same project, same environment.
6. Observe: the CLI produces no `CustomKeyInConfigDeprecation` warning.

The discrepancy between steps 4 and 6 is the bug.

### Log output/Screenshots

### Operating System

macOS

### dbt version

dbt-core 1.11.11

### dbt Adapter

dbt-exasol 1.10.6

### dbt Power User version

0.61.6

### Are you willing to submit PR?

- [x] Yes I am willing to submit a PR!