Cloud routines (CCR) egress proxy blocks reaching third-party APIs — no user-configurable allowlist

## Description

A scheduled Cloud routine (created via the Claude Code `/schedule` flow, backed by the `RemoteTrigger` API) needs to call a third-party SaaS API from Bash inside its CCR sandbox (environment kind `anthropic_cloud`, id `env_01VtnYFmhfbnP7L1TDMDVbDy`). Every outbound HTTPS call to that host fails at the network layer:

```
error connecting to API: error sending request for url (https://api.hotdata.dev/v1/databases/...)
[agent-proxy] While this command ran, 12 connections through the agent proxy failed:
- api.hotdata.dev:443 — connect_rejected (the egress proxy denied the CONNECT (organization policy) or could not reach the destination)
```

Querying the sandbox's own proxy status endpoint (`curl http://127.0.0.1:/__agentproxy/status`) confirms the egress proxy's allowlist only covers:
- Anthropic's own APIs (`api.anthropic.com` and friends, `mcp-proxy.anthropic.com`)
- A handful of package registries (`registry.npmjs.org`, `pypi.org`, `files.pythonhosted.org`, `index.crates.io`, `jsr.io`, etc.)

There is no setting — in the routine config, environment config, or account settings — to add an arbitrary third-party API host to that allowlist. MCP-connector traffic (e.g. Gmail, HubSpot) works fine from the same routine because it's routed through the separate MCP proxy; only direct outbound HTTPS from Bash/CLI tools hits this restrictive allowlist.

## Impact

Any Cloud routine that needs to call a legitimate third-party API/CLI directly (not via an existing MCP connector) is permanently blocked, with no workaround available to the user — this isn't a credentials or configuration issue on the routine's side, it's a hard network-policy wall with no escape hatch.

## Repro steps

1. Create a routine via `/schedule` (or the `RemoteTrigger` API) targeting the "Default" `anthropic_cloud` environment.
2. Give it a prompt that runs a Bash command calling any non-allowlisted third-party API host over HTTPS.
3. Every connection attempt is rejected by the agent proxy before reaching the destination, with `connect_rejected (... organization policy ...)`.

## Evidence

- environment_id: `env_01VtnYFmhfbnP7L1TDMDVbDy`
- 4 identical failing runs reproduced on 2026-09-07: session ids `cse_01NnDSTPcRXvHM3ATEpkvGHv`, `cse_0164WMKoTxVhUsEwZjqxmPnc`, `cse_01BufC55gg5TPjUKSi8ikZvY`, `cse_015Wnn8caCPZAe3fFzrLbcov`
- Target host: `api.hotdata.dev:443`
- Each run independently confirmed the block via its own `/__agentproxy/status` check rather than guessing

## Suggested fix

Expose a user-configurable egress allowlist per environment (or per routine) so a routine's own legitimate third-party API calls aren't unconditionally blocked — e.g. a list of allowed hostnames settable from the routine/environment configuration UI or API.

Start with the Claude Code /schedule flow and RemoteTrigger API, then inspect how the anthropic_cloud environment exposes configuration and how the agent-proxy status endpoint reports its allowlist. Confirm the intended per-environment or per-routine configuration surface and its security boundaries; done means an authorized user can add a host and direct HTTPS calls succeed without changing MCP behavior.

Written by the indexing model from the issue text.