agent: resolve_scope ignores the Authorization bearer that get_user_workspace_client already accepts

[zuckerberg-db]

Found by isaac review of genie-agent vs main. The code shape is real; the reviewer's
stated impact is not, and the correction matters for prioritising this.

What happens

resolve_scope gates on one header only:

# agent/agent_server/utils_memory.py:42
if headers.get("x-forwarded-access-token"):
    return get_user_workspace_client().current_user.me().id
if os.getenv("DATABRICKS_APP_NAME"):
    return None          # -> _require_scope raises 401 (agent.py:112)

The helper it calls one line earlier already handles the other case:

# agent/agent_server/utils.py:38-41
auth = headers.get("authorization") or headers.get("Authorization") or ""
    token = auth[7:].strip()

So when identity arrives as Authorization: Bearer and x-forwarded-access-token is absent,
resolve_scope returns None and the request 401s — even though get_user_workspace_client
could have resolved the user perfectly well. The gate is narrower than the capability behind it.

Correcting the review

isaac review concluded that "every invoke/stream request 401s and the agent is unusable through
the proxy." That is not what happens. Every E2E run has recorded app.data_path_status=200
with guest data queries working, so the Databricks Apps front door evidently does populate
x-forwarded-access-token from the bearer. The 401 path is latent, contingent on a front door
that does not do that.

Filing it anyway because the asymmetry is a trap: anyone who changes how the token is forwarded,
or who calls the agent from something other than Apps, gets a 401 whose cause is two functions
away from where it surfaces.

Suggested fix

Mirror get_user_workspace_client's fallback in resolve_scope: when x-forwarded-access-token
is absent, accept an Authorization bearer before falling through to the None/401 path.