feat(sqlserver): Part 9 — dbt init profile wizard

[axellpadilla]

Part of the SQL Server Fusion adapter Part-series (plan/02-implementation-steps.md §5.3.1). Stacked on #18 (Part 8) since dbt-init transitively depends on dbt-loader.

What this adds

• crates/dbt-init/src/adapter_config/sqlserver_config.rs: InteractiveSetup impl for SqlServerDbConfig (already defined in dbt-schemas from Part 2 — no schema changes needed here).
• AdapterType::SqlServer added to get_available_adapters() and the create_profile_for_adapter() match arm in profile_setup.rs.
• Export wired through adapter_config/mod.rs.

Non-mechanical decisions

• All four dbt-auth auth methods are exposed, not just the two Fabric's wizard exposes. Fabric's fabric_config.rs comments out ActiveDirectoryPassword ("didn't find the right credentials to test it") and has no sql branch at all. Both are fully implemented and unit-tested in dbt-auth/src/sqlserver/mod.rs's parse_auth (confirmed by reading it directly), and sql is v1's actual default auth mode for SQL Server (unlike Fabric, which defaults to Entra). Leaving them out would silently regress wizard coverage below what the adapter can already do.
• sql is first in the select list and the wizard default, matching v1's default (sqlserver_credentials.py) rather than dbt-auth's DEFAULT_AUTH constant (ActiveDirectoryServicePrincipal, shared with Fabric — changing it would change Fabric's default too, out of scope here per 02-implementation-steps.md §5.4's note on the same constant).
• client_id/user/password fields are reused across two auth branches (Service Principal vs. Password) via duplicate ConfigField entries with different prompts/conditions — same struct field, mutually exclusive display, no ambiguity since only one authentication value is ever selected.
• No advanced/rarely-touched fields are prompted (encrypt, trust_cert, login_timeout, query_timeout, retries, schema_authorization, trace_flag, threads, driver) — matches Fabric's own scope minimalism. encrypt/trust_cert get sane defaults (true/false, matching both SqlServerDbConfig's doc comments and dbt-auth's DEFAULT_ENCRYPT/DEFAULT_TRUST_CERT) baked into default_sqlserver_config(); the rest are left None and fall through to their documented defaults elsewhere.
• No tests added. Checked first: zero adapter_config/*.rs files in this crate have any test coverage today (including fabric_config.rs, the file this one is modeled on) — the only tests in the crate are in init.rs and profile_setup.rs. This differs from Part 8's loader macros, where real behavioral test precedent existed and was matched; here there's no precedent to deviate from.
• Not a port: v1 (dbt-sqlserver, Python) has no equivalent interactive wizard — this is v2-only functionality, so there's no v1 source to diff against.

Verification

• cargo check -p dbt-init: clean.
• cargo clippy -p dbt-init --all-targets: clean.
• cargo test -p dbt-init: 7/7 passing (pre-existing; none touch adapter_config).
• cargo fmt -p dbt-init applied.
• Confirmed no other exhaustive AdapterType match site in this crate needed a new arm (grep -rn "AdapterType::Fabric" crates/dbt-init/src/ returns only the two sites touched here; init.rs has no AdapterType references at all).

Closes #9