fix: harden credential redaction in logged SQL

[SreeramaYeshwanthGowd]

Resolves #1609

Description

redact_credentials is applied to every logged statement (connections.py:244 and :342), but the
COPY INTO pattern behind it misses several shapes, so secrets can reach logs/dbt.log verbatim: an
uppercase CREDENTIAL (...) clause, the encryption (...) clause that databricks_copy_into emits
itself, a dotted key such as 'fs.azure.account.key', a value containing a newline, and every clause
after the first.

The same function has two problems that are not leaks. Splitting the clause body on , raises
ValueError: not enough values to unpack when a value contains a comma, and because the call sits on
line 244 before the try: on line 246, the exception escapes while the context manager is being
entered, so the statement never runs. Separately, '.*?' inside a repeated group backtracks
exponentially on an unterminated clause.

Fix: match credential and encryption case-insensitively, recover the keys with a regex instead
of splitting on ,, and sub every clause. A quoted value is described as
'(?:[^']|'(?!\s*[,)]))*', which treats a quote followed by a delimiter as the closing quote and any
other quote as part of the value. That keeps the match linear and still redacts values containing a
quote. A cheap substring test runs first so the common no-clause path does not pay for the
case-insensitive scan; a 36 KB statement with no clause ends up faster than before, and the
pathological input drops from roughly 24 s to sub-millisecond.

The keyword deliberately has no \b prefix. The current lookbehind has no boundary requirement, so
storage_credential (...) is redacted today, and adding one would silently narrow coverage. Key names
are preserved and every value in a matched clause is redacted, including a non-secret one such as
'TYPE' = 'AWS_SSE_C', which matches the existing behaviour for credential (...).

Scope note: this repairs the existing COPY INTO redaction only. Other syntax that can carry
secrets, such as the OPTIONS (...) clause, is out of scope here.

Testing: 1321 passed, 5 skipped on the unit suite. The three existing redaction tests are
unchanged and still pass byte for byte, which confirms no behaviour regression. Ten cases are added,
one per shape above plus negative cases proving that credential_id = 1 and a clause with no
'key' = 'value' options are left alone. No functional test is included because log redaction is not
observable against a warehouse.

Checklist

• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt-databricks next" section.

[SreeramaYeshwanthGowd]

Flagging that I have three small fixes open: #1613, #1610 and #1612. Could someone approve the fork workflow runs on #1610 and #1612 so CI can report? #1613 is already green.

If it helps with review order, #1613 is the smallest. #1612 is the one that would benefit most from an /integration-test run, ideally against a cluster below DBR 17.1, since that is the branch it changes.

[SreeramaYeshwanthGowd]

@sd-db @jprakash-db Merged main and cleared the changelog conflict, so this is ready again. No rush, just flagging in case it helps.

[sd-db]

Thanks for working on this. I found one remaining redaction edge case: an escaped apostrophe immediately before , or ) can be mistaken for the end of the secret value. This affects both SQL doubled apostrophes ('') and backslash escapes (\').

I prepared a narrow follow-up in [602987d](602987d). It keeps redaction best-effort and fail-open.

Could you use or cherry-pick this commit into the PR?

[SreeramaYeshwanthGowd]

@sd-db Thanks for the fix. Pulled in 602987d as a fast forward so your authorship stays intact. Full unit suite and pre commit hooks pass locally.