[Subtask] Standalone Lance REST: caller identity forwarding and its follow-ups

### Describe the subtask

#9087 scoped metadata authorization to auxiliary mode and left standalone per-user identity out of scope. This subtask opens that track.

Today standalone Lance REST authenticates the caller and then makes every Gravitino call as one configured service account (`gravitino.lance-rest.gravitino-auth-type` = `simple` / `oauth2`). Unlike Iceberg REST — which only reads catalog configuration through its Gravitino client and does all metadata work against the backend catalog — Lance REST performs its metadata *writes* through Gravitino, so a service account means every table is owned by `lance-rest-server`, audit never records the real user, and Gravitino's privilege model does not apply to Lance users.

The plan, in order:

1. Forward the caller's credentials per request (sub-issue below; PR #12984). Lands after #12954 so the auth documentation is in place; the `LanceExceptionMapper` conflict resolves in favour of #12954 (no stack traces in 401/403).
2. Fix the client bootstrap so the first caller's credentials are not used to load the metalake (#12985).
3. Document and then close the authorization-semantics gap between the two modes (#13089).
4. Replace raw credential replay with token exchange, which removes the Kerberos and dual-audience limits and stops Lance REST acting as a credential relay (#13092).

One auxiliary-mode item sits alongside the standalone steps rather than in their sequence: `LanceServiceIdentityFilter` runs anonymous requests as the service user, which under `simple` authentication plus `gravitino.authorization.enable = true` turns an unauthenticated request into an authorized one (#13093). #12984 closes the equivalent hole on the standalone side; the auxiliary filter is a separate code path and needs its own fix.

Step 1 is deliberately an intermediate state: it is the smallest change that makes Gravitino's ownership, audit and privilege model apply to standalone Lance users, and its `AuthDataProvider.getRequestHeaders()` extension point is the seam step 4 plugs into.

### Parent issue

#9087

Start with AuthDataProvider.getRequestHeaders() and the standalone Lance REST authentication path described here; review PR #12984 and the dependency on #12954 first. Check how LanceExceptionMapper handles 401/403 responses, then trace the follow-up issues #12985, #13089, #13092, and #13093. Done means the planned caller-identity, bootstrap, authorization, token-exchange, and auxiliary-mode gaps are addressed or cleanly split among those follow-ups.

Written by the indexing model from the issue text.