Workspace-level provider secret is not injected into the MDA runtime, but mda deploy preflight accepts it

# Workspace-level provider secret is not injected into the MDA runtime, but `mda deploy` preflight accepts it

## Summary

`mda deploy` preflight explicitly offers two ways to supply a provider key: the project `.env`, or a LangSmith workspace secret. Only the first one works.

When `OPENAI_API_KEY` is present as a workspace secret (Settings → Workspaces → Secrets) and absent from `.env`, the preflight check passes and the deploy succeeds, but the deployed container raises `openai.OpenAIError: Missing credentials` on every request that compiles the agent. Supplying the same key value via `.env` on the next deploy resolves it immediately.

Because the failure occurs inside `get_graph`, it affects `/assistants/{id}/graph`, `/assistants/{id}/subgraphs`, and every run — while `/info` and `/assistants/search` continue to return 200, making the deployment appear healthy.

## Environment

- `managed-deepagents` CLI v0.6.1
- `langgraph-api` 0.12.6
- LangSmith Cloud, US region
- Deployment type: Serverless (Managed Deep Agent)
- Python project scaffolded via `mda init`
- macOS 15, `uv`

`agent.py`:

```python
from managed_deepagents import define_deep_agent

agent = define_deep_agent(
name="research-assistant",
model="openai:gpt-5.5",
tools=[{"type": "web_search"}],
)
```

## Steps to reproduce

1. `mda init research-assistant && cd research-assistant`
2. Supply `OPENAI_API_KEY` to the local environment by some means **other than** a `.env` file (in my case macOS Keychain via `direnv`). Confirm `mda dev .` works — the agent runs and calls web search successfully.
3. Do **not** create a `.env` file.
4. Run `mda deploy .`. Preflight fails with:

```
⚠ OPENAI_API_KEY is not configured
The agent model 'openai:gpt-5.5' requires OPENAI_API_KEY, but it is not set in
/.env and not configured as a LangSmith workspace secret.
Add `OPENAI_API_KEY=...` to /.env, or add it under
Settings > Workspaces > Secrets in LangSmith (https://smith.langchain.com),
then deploy again. Values exported in your shell are not read.
```

5. Follow the second suggestion: add `OPENAI_API_KEY` under Settings → Workspaces → Secrets. Verify it appears in the correct workspace and organization.
6. Run `mda deploy .` again. Preflight now passes; deploy completes; deployment reports **Currently deployed**.
7. `GET /assistants/{assistant_id}/graph?xray=true` → **500**
8. `POST /runs/wait` → HTTP 200, body `{"__error__": {"error": "OpenAIError", "message": "An internal error occurred"}}`
9. Cut a **New Revision** to force a fresh container that reads current secrets at startup. Repeat steps 7–8. Same results.

## Expected

The workspace secret is injected into the deployment runtime, and the agent compiles.

## Actual

`OPENAI_API_KEY` is absent from the container environment. Server Logs:

```
openai.OpenAIError: Missing credentials. Please pass an `api_key`,
`workload_identity`, `admin_api_key`, or set the `OPENAI_API_KEY` or
`OPENAI_ADMIN_KEY` environment variable.
```

Abridged traceback (identical on every affected request):

```
File "/api/langgraph_api/api/assistants.py", line 314, in get_assistant_graph
File "/api/langgraph_api/graph.py", line 397, in get_graph
File "/api/langgraph_api/_factory_utils.py", line 188, in invoke_factory
File "/deps/source/_mda_entry.py", line 18, in agent
return compile_managed_agent(_definition, config, ...)
File ".../managed_deepagents/runtime.py", line 651, in compile_managed_agent
agent = _create_deep_agent(**merged)
File ".../deepagents/graph.py", line 606, in create_deep_agent
model = resolve_model(model)
File ".../deepagents/_models.py", line 57, in resolve_model
return init_chat_model(model, **apply_provider_profile(model))
File ".../langchain_openai/chat_models/base.py", line 1441, in validate_environment
self.root_async_client = openai.AsyncOpenAI(
File ".../openai/_client.py", line 947, in __init__
raise OpenAIError(
openai.OpenAIError: Missing credentials.
```

Reproduced across two independent revisions, each a fresh container start.

## Workaround

Materialize `.env` for the duration of the deploy only:

```bash
printf 'OPENAI_API_KEY=%s\n' "$OPENAI_API_KEY" > .env && mda deploy . ; rm -f .env
```

The next `GET /assistants/{id}/graph?xray=true` returns 200 and runs complete normally, with `web_search_call` blocks and `url_citation` annotations as documented. Same key value, same project, same model string — only the delivery mechanism changed.

## Secondary issue: the failure surfaces in the browser as a CORS error

The 500 response path does not attach `Access-Control-Allow-Origin`, so LangSmith Studio and the deployment page's own graph preview report:

```
GET https://.us.langgraph.app/assistants//graph?xray=true
net::ERR_FAILED 500 (Internal Server Error)
Access to fetch at '...' from origin 'https://smith.langchain.com' has been
blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.
```

Studio's user-facing message is `Unable to connect to LangGraph server. Please ensure the server is running and accessible. Original error: Failed to fetch` — which points at server availability rather than the actual missing credential. The server was reachable and returning 200 on `/info` the entire time.

Attaching CORS headers on the error path, and surfacing the underlying error detail rather than a bare `Internal Server Error` body, would make this class of failure diagnosable from the UI.

## Suggested fixes

1. Inject workspace secrets into the deployment runtime, or
2. Remove workspace secrets from the preflight's suggested remedies and from what the preflight accepts as satisfying the check, so a deploy cannot pass validation on a credential path the runtime does not read.
3. Attach CORS headers on 5xx responses so browser clients report the real status.
4. Return the exception detail in the `/assistants/{id}/graph` 500 body.