[codex] Support multiple forced ChatGPT workspaces

[rreichel3-oai]

Summary

This change lets forced_chatgpt_workspace_id accept multiple workspace IDs instead of a single value.

It keeps the existing config key name, adds backward-compatible parsing for a single string in config.toml, and normalizes the setting into an allowed workspace list across login enforcement, app-server config surfaces, and local ChatGPT auth helpers.

Why

Workspace-restricted deployments may need to allow more than one ChatGPT workspace without dropping the guardrail entirely.

Server-side impact

Codex's local server and app-server protocol needed changes because they previously assumed a single workspace ID. The local login flow now matches the auth backend interface by sending the allowed workspace list as a single comma-separated allowed_workspace_id query parameter.

Validation

This was tested with:

• A single workspace config
• With multi-workspace configs
• With multiple workspaces in the config
• The user only being a part of a subset of them

All were successful.

Automated coverage:

• cargo test -p codex-login
• cargo test -p codex-app-server-protocol
• cargo test -p codex-tui local_chatgpt_auth
• cargo test --locked -p codex-app-server login_account_chatgpt_includes_forced_workspace_allowlist_query_param

[owenlin0]

codex flagged this, mind taking a look? the rest looks good! nice catch on the agent identity thing

Potential regression: config/read looks like it can fail for existing configs that still use the legacy single-string shape.

Scenario:

1. A user has forced_chatgpt_workspace_id = "ws_123" in config.toml. This branch still accepts that as ForcedChatgptWorkspaceIds::Single, so normal config loading works.
2. ConfigManagerService::read loads the effective config into ConfigToml, then serializes it with serde_json::to_value(&effective_config_toml) and deserializes it into the v2 API Config.
3. The untagged enum serializes the single form as JSON string: { "forced_chatgpt_workspace_id": "ws_123" }.
4. The v2 API type now expects Option<Vec<String>>, so it expects { "forced_chatgpt_workspace_id": ["ws_123"] }.

That means config/read can return a deserialization error for an existing valid single-string config. The fix should normalize this field before the API round-trip, or use a compatibility conversion/type for the API config response.