docs: correct Azure Entra OAuth kernel support in connection param reference (#509) * docs: correct Azure Entra OAuth kernel support in connection param reference The connection-parameter reference (added in #457) predated #505 (feat(kernel): thread Azure Entra auth (U2M + SP M2M) through the kernel path) and still claimed the kernel "rejects Azure-direct (Entra) OAuth". That is now inverted: buildKernelConnectionOptions (lib/kernel/KernelAuth.ts) has a dedicated AzureSpM2m mode for Entra- direct service-principal M2M and consumes both azureTenantId and useDatabricksOAuthInAzure. - Authentication table: azureTenantId / useDatabricksOAuthInAzure kernel cell ❌ → ⚠️, with an accurate flow-selection note. - authType "supported on both" note now mentions Azure Entra SP M2M. - Summary of gaps: drop Azure from "missing/ignored on Kernel" (renumber) and record it under "Behavioral divergences to watch" instead. Other cross-backend rows spot-checked against source and left as-is. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * docs: mark Azure OAuth options fully supported (✅) on kernel Per design intent: all U2M routes to the cloud-blind in-house OAuth U2M flow (no Azure-specific U2M mode), so `.databricks.azure.us` (US-gov) is always supported via that flow — that is intended completeness, not a support gap. Both `azureTenantId` and `useDatabricksOAuthInAzure` are read and forwarded on both backends, so the kernel cell is ✅ (not ⚠️). Notes reframed: US-gov behavior now reads as the kernel being more complete than Thrift (whose useDatabricksOAuthInAzure-true arm rejects US-gov), and useDatabricksOAuthInAzure documented as selecting only the M2M mechanism. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * docs: add token, staticToken, and oauthClientSecret rows to auth table The Authentication table documented `authType` and the OAuth modifier options but never gave the credential-bearing fields their own rows — `oauthClientSecret` in particular was only named inline as the flow selector, despite its non-trivial kernel mapping (remapped to `azureClientSecret` on the Entra-direct arm) and a blank-handling divergence (rejected only on the Azure SP arm). Adds three rows, each with the Thrift↔kernel mapping verified against source: - `token` (PAT): Thrift PlainHttpAuthentication vs kernel native `Pat`; kernel rejects blank/reserved + OAuth-field pairing, Thrift does not. - `staticToken`: Thrift StaticTokenProvider (federation opt-in) vs kernel `Pat` bearer with federation always on. - `oauthClientSecret` (M2M): flow selector on both; kernel native `oauthClientSecret` or remapped `azureClientSecret`. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * ai: apply changes for #509 (2 review threads) Addresses: - #3847919330 at CONNECTION_PARAMETERS.md:65 - #3848004541 at CONNECTION_PARAMETERS.md:68 Signed-off-by: peco-engineer-bot[bot] * ai: apply changes for #509 (1 review thread) Addresses: - #3848036730 at CONNECTION_PARAMETERS.md:68 Signed-off-by: peco-engineer-bot[bot] * ai: apply changes for #509 (1 review thread) Addresses: - #3848073178 at CONNECTION_PARAMETERS.md:60 Signed-off-by: peco-engineer-bot[bot] * docs: merge the two oauthClientId rows into one complete row The table had two oauthClientId entries both describing the U2M/no-secret case (one about defaulting, one about flow-selection), which read as two different options, used inconsistent cell notation (✅ vs ✅ (U2M)), and omitted M2M entirely. The flow-selection parity is also now covered by the oauthClientSecret row. Merged into a single oauthClientId row covering both flows: forwarded verbatim when set; defaults to `databricks-sql-connector` when absent (Thrift getClientId() for both flows; kernel `?? DEFAULT_OAUTH_CLIENT_ID` on M2M, napi's own default on U2M); retains the "id + no secret ⇒ U2M, no secret-required error" parity note. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * docs: restore Azure kernel support to ✅ with a 1.0.0 version floor The review-bot hedged the Azure row to ⚠️ because the pinned 0.2.0 native binary might predate the AzureSpM2m surface. With a 1.0.0 kernel binary (which carries kernel#282), the Entra-direct M2M arm is implemented at runtime, so the row is ✅ again. Replaces the "0.2.0 may predate / not observable / confirm your build" hedges (Azure row + authType note) with a concrete, checkable version floor: the Entra-direct M2M arm needs the native binary >= 1.0.0; U2M works on any build. Per the ✅ legend (option is read and forwarded), the connector honors these options on both backends; the binary floor is a deployment note, not a support downgrade. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * docs: phrase kernel 1.0.0 as forthcoming, not an existing version floor 1.0.0 is not published yet, so "carried by the native binary from 1.0.0 onward" overstated it as a shipping fact. Reword the Azure row and the authType note: the connector forwards AzureSpM2m today, but its runtime path needs the kernel Azure SP surface (kernel#282), which the currently pinned 0.2.0 binary predates — it lands in a forthcoming release (planned 1.0.0, not yet published). U2M still needs no minimum. Row stays ✅ (the options are read and forwarded per the legend). Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * ai: apply changes for #509 (1 review thread) Addresses: - #3848192767 at CONNECTION_PARAMETERS.md:67 Signed-off-by: peco-engineer-bot[bot] * docs: drop kernel binary/version hedging from the Azure rows Per direction, treat the kernel Azure SP surface as included. Remove the "0.2.0 predates it / planned 1.0.0, not yet published" caveats from both the Azure row and the authType note; Azure is ✅ on both backends with a clean flow-selection description. Co-authored-by: Isaac Signed-off-by: eric-wang-1990 * ai: apply changes for #509 (1 review thread) Addresses: - #3848237239 at CONNECTION_PARAMETERS.md:66 Signed-off-by: peco-engineer-bot[bot] * docs: run prettier on CONNECTION_PARAMETERS.md Reformat the Authentication table to match prettier's column padding so the lint check passes. Whitespace-only, no content change. Signed-off-by: eric-wang-1990 --------- Signed-off-by: eric-wang-1990 Signed-off-by: peco-engineer-bot[bot] Co-authored-by: peco-engineer-bot[bot]

Uh oh!