fix: avoid implicit bundle target for non-bundle auth resolution

[jmahotiedu]

## Summary

• Stop loading bundle auth configuration implicitly in MustWorkspaceClient unless --target / --environment is explicitly set.

• Keep explicit target behavior unchanged so bundle context remains opt-in.

• Add regression tests covering:

  • Non-bundle command inside bundle directory respects DATABRICKS_HOST.
  • Explicit --target still uses bundle target host.

## Problem
Fixes #4502. Non-bundle commands such as databricks current-user me were resolving authentication from the bundle’s default target when run inside a bundle directory, potentially overriding DATABRICKS_HOST.

## Testing

• go test ./cmd/root

[NateWerner]

I just recently had a 1 hour troubleshooting session trying to figure out why an Azure SP could not login to a test environment when it worked in dev in my Github Workflow, when I finally realized it was not actually logging into test, but following the bundle's default environment. In my case I have a utility workflow script (running in a folder that also has DAB) that is doing non-bundle related items with CLI that was relying on my workflow's DATABRICKS_HOST env var.
Feels odd to spray "-t " all over my non-bundle Databricks utility script.
Thanks for proposing this change.

[jmahotiedu]

Thanks @NateWerner, this is exactly the real-world failure mode this PR is intended to fix.

With this change, bundle auth is only used when --target / --environment is explicitly provided. For non-bundle commands, even inside a DAB directory, auth resolution respects DATABRICKS_HOST; explicit -t behavior remains unchanged.

@andrewnester if you have bandwidth, could you please approve workflow execution for #4504 so required checks can run? Happy to make any follow-up changes.

[andrewnester]

We had an internal discussion about this and we would like to keep auth resolved based on bundle configuration but we want to make any explicit configurations (--profile flag or env vvariables suich as DATABRICKS_HOST) take the precedence. This would solve the issue in #4502

The reason being is if someone uses non-bundle command, for example, databricks apps list in bundle context we want the auth to be resolved to the same configuration as bundle ones, for example, someone might want to confirm the resource being created or do additional post-processing using CLI commands after bundle deploy.

cc @simonfaltum

[jmahotiedu]

Thanks for the clarification @andrewnester. I agree with this direction and updated the PR to match it.

Implemented in aa286c795:

• Keep bundle-based auth as the default in bundle context.
• If no --target/--environment is set, explicit auth inputs take precedence (--profile and auth env vars such as DATABRICKS_HOST).
• If --target / --environment is explicitly set, target-selected bundle auth still wins.

So for databricks apps list in bundle context:

• no explicit auth input => resolves like bundle commands (default target),
• explicit auth input => uses the explicit config.

I also expanded tests to cover this precedence matrix (including --environment parity and non-auth env no-op), and go test ./cmd/root -count=1 is passing.

Happy to adjust further if you want any precedence edge cases handled differently.

[github-actions]

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

• PR number: 4504
• Commit SHA: aa286c795a1257d2d1772969e024f5c03c616a9e

Checks will be approved automatically on success.