perf: heavy per-request current_user.me() OBO round-trips on every API call

Summary

The dfra customer's prod logs show that essentially every authenticated API
call performs a full user-details lookup via the Databricks SDK
current_user.me() over an OBO (on-behalf-of) workspace client:

INFO - Using OBO token with current_user.me() for user lookup (no admin permissions required).
INFO - Reusing cached OBO workspace client for user: <user>
INFO - UsersManager: Fetching current user details via current_user.me()
INFO - UsersManager: Successfully retrieved current user info for: <user>

This block repeats for /data-products, /data-contracts, /approvals/queue,
/semantic-models/stats, /notifications, etc. — often several times within a
single page load. The OBO workspace client is cached ("Reusing cached OBO
workspace client"), but the current_user.me() call itself is not — each
request makes a fresh network round-trip to the Databricks control plane to
resolve the same user identity.

Surfaced while investigating dashboard slowness for dfra (PR #596). It is not
the dominant cost there (semantic-models cache recompute was, fixed in #596),
but per-request control-plane round-trips add latency to every call and scale
poorly with dashboard fan-out (a single dashboard load fires ~8-10 API calls,
each re-resolving the same user).

Proposed direction (needs investigation)

• Cache the resolved user-details object per user for a short TTL (e.g. keyed by
  forwarded email / user id), not just the workspace client. Most requests
  within a session resolve the same identity repeatedly.
• Confirm which fields callers actually need from current_user.me() — if it's
  just email/groups/username, those often already arrive via the
  X-Forwarded-* proxy headers and may not need an SDK call at all for the hot
  paths.
• Ensure any cache respects impersonation / test-persona headers so cached
  identity can't leak across users.

Acceptance

• A page load that fires N API calls does not trigger N separate
  current_user.me() round-trips for the same user.
• Identity resolution remains correct across users and impersonation.

Found during dfra perf investigation; see PR #596. Related: #601 (ApprovalsManager wiring).

Start at the UsersManager path that calls the Databricks SDK current_user.me() and trace its callers across the listed API endpoints. Review forwarded email, user ID, and impersonation or test-persona headers before choosing a cache boundary; done means repeated requests for one user avoid repeated lookups while identity remains correct across users.