PR #315: `timeout=getattr(credentials, "login_timeout", None)` is a no-op on every call site

[sdebruyn]

Summary

#315 adds timeout=getattr(credentials, "login_timeout", None) to every get_token() call. The change is functionally a no-op on every call site, for two independent reasons:

1. login_timeout does not exist as an attribute on FabricCredentials, so getattr(credentials, "login_timeout", None) always returns None.
2. get_token() in azure-identity does not accept a timeout argument; it silently disappears into **kwargs and never reaches any underlying HTTP call.

Evidence

The #315 diff shows the parameter being threaded through every get_token() invocation, but dbt/adapters/fabric/fabric_credentials.py does not declare a login_timeout field, and the azure-identity SDK's TokenCredential.get_token signature does not accept a timeout keyword.

User impact

• Users who configured login_timeout in their profile (or who saw the parameter in release notes and expected it to do something) see no behaviour change.
• The parameter is dead code: it touches every auth path but affects none.

Suggested fix

Either:

1. Revert the change, since it has no effect.
2. Actually implement a login timeout. That requires (a) adding login_timeout: Optional[float] = None to FabricCredentials, (b) wrapping get_token() in a real timeout — concurrent.futures.ThreadPoolExecutor + Future.result(timeout=...) is one option, or azure.core.pipeline.policies.RetryPolicy for the underlying HTTP layer.

The first option is preferable: the dbt adapter is not the right layer to invent token-acquisition timeouts when Azure SDK callers don't have a documented timeout knob there.

Happy to open a PR alongside if useful.