Verify the service-principal token recipe with real credentials

[ivanvyd]

docs/authentication.md documents how to mint a token for a Databricks service principal so
unattended runs — CI, a scheduled Question Pack — work without anyone's personal access token. The
recipe has never been run with real service-principal credentials.

What is already verified

The endpoint accepts the request exactly as documented. Deliberately wrong credentials return:

HTTP 401
{"error":"invalid_client","error_description":"Client authentication failed"}

invalid_client rather than 404 or invalid_request means the URL, the POST method, the HTTP
Basic form and the form parameters are all correct — the credentials are the only thing rejected.
Credentials supplied in the request body were confirmed to be accepted the same way, which is what
lets the documented recipe keep the secret out of argv.

What has not been exercised is the step after that: valid credentials returning a usable token,
and that token driving a real pack run.

Note on where the risk actually is

The LakeSpeak side of this is already well covered — DATABRICKS_TOKEN is exercised by every live
test run. The unverified part is a pure Databricks flow. So this is about the recipe being correct
and complete, not about the client.

What closing this looks like

1. Create a service principal and an OAuth secret in the Databricks account console.
2. Grant it access to a Genie Agent and its SQL warehouse — it inherits nothing from you, which is
   the step most likely to be missed.
3. Run the documented recipe, then a real pack:

   lakespeak agents list      # fastest confirmation of what it can actually reach
   lakespeak pack run packs/<your-pack>.yaml

4. Record the result in docs/compatibility.md, including anything the documentation failed to
   mention — that is the most valuable part of this issue.

examples/github-actions/daily-brief.yml uses the same recipe, so closing this validates that
sample too.