BLOCKED(env): 远程执行环境拉不到任何容器镜像 ⇒ AT-E003/AT-T001–T008 行为层与全部 apps/api vitest 无法执行

> 由 #3003（AT 验收 B1+B2）定级过程中实测发现。绑定 SHA `938d16bf3a49c4047f42bbc697833cd921d1053e`（工作树 clean，`git status --porcelain` 空）。
> 环境：Claude Code on the web 远程执行容器（非人类本机 macOS 工作区）。

## 现象

该环境**任何 registry 的镜像 blob 都被网络策略拒绝**，manifest 能取到、blob 一律 403：

```
$ docker pull pgvector/pgvector:pg16
failed to copy: httpReadSeeker: failed open: failed to do request:
Get "https://production.cloudfront.docker.com/registry-v2/.../data?...": Forbidden

$ docker pull ghcr.io/linuxcontainers/alpine:latest
failed to copy: httpReadSeeker: failed open: failed to do request:
Get "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:...": Forbidden
```

出口代理自己的状态口也确认这是**网关策略拒绝**，不是 TLS/证书问题：

```
$ curl -sS "$HTTPS_PROXY/__agentproxy/status"
"recentRelayFailures": [
{ "kind": "connect_rejected",
"detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host": "production.cloudfront.docker.com:443" } ]
```

docker daemon 本身是可用的（`dockerd` 已起、`docker ps` 正常、已配 `HTTPS_PROXY` 与系统 CA），拉不动的是镜像层。这是策略，不绕。

## 直接后果（各层实测，不是推断）

### ① 全部 `apps/api` vitest 无法执行——包括不连库的那些

`apps/api/vitest.config.ts` 挂了 `globalSetup: tests/support/db-global-setup.ts`，它无条件 `ensureDatabase()`；`ensureDatabase()` 的存活探针写死 `docker compose exec -T postgres pg_isready`（`apps/api/tests/support/db.ts:80-88`），探针失败就 `docker compose up -d postgres` → 拉镜像 → 403。

```
❯ Module.ensureDatabase tests/support/db.ts:111:7
Error: Command failed: docker compose ... up -d postgres
Image pgvector/pgvector:pg16 Pulling
... : Forbidden
```

**⚠ 附带的真实缺陷（与镜像策略无关，值得单独修）**：本仓已有 `WORKSPACEX_REUSE_INFRA=1` 这个「复用既有基础设施」的开关，但它挡在 `postgresReady()` **之后**——而 `postgresReady()` 唯一实现是 `docker compose exec`。于是「机器上已经有一个可连的 PostgreSQL」这件事**在代码里无法表达**：本环境 `/usr/lib/postgresql/16/bin` 齐全、`psql` 可用、可以起一个原生 cluster 监听 `with-test-isolation` 派发的 `PGPORT`，却没有任何受支持的路径让 `apps/api` 的测试用它。建议把探针改成「先按 `PGHOST/PGPORT` 直连试一次 TCP，连不上再回落 docker」——TCP 探针正是该文件注释里论证过的诚实信号，改动很小。

### ② `apps/skill-sandbox test`：3 个文件 0 条断言（基线是 16 files / 72 passed / 0 failed / 1 skipped）

```
Test Files 3 failed | 13 passed (16)
Tests 66 passed | 7 skipped (73)
```

三个红全部停在 `beforeAll` 的 `docker build -t workspacex-skill-sandbox:test .`（基础镜像拉不动），一条用例断言都没跑：

- `tests/container-network-isolation.test.ts`
- `tests/office-skills-container-network-isolation.test.ts`
- `tests/produces-real-cjk-pdf.test.ts` ← **#3003 正文只预告了前两个，这是第三个**

注意与 #3003 提到的「本地撞满 600s timeout 被 skip」**不是同一现象**：这里是秒级失败（拉取被拒），不是超时。

### ③ `deep-agent-service` 的 E003 容器 lane：17 条 skip

`tests/native_sandbox_fixture.py:44` 要求 `WX_NATIVE_SANDBOX_CONTAINER`：

```
SKIPPED [17] tests/native_sandbox_fixture.py:44: Requires an explicitly owned E003 integration container
```

其中 **`tests/test_native_file_tools.py` 的 8 条整体 skip**，而这 8 条正是 T001–T008 一对一的行为断言
（`test_t001_unicode_listing_missing_path_and_sibling_isolation` … `test_t008_python_calculation_and_nonzero_execution`）。

另有 6 条 skip 要求 `real PostgreSQL wrapper DSN`（`tests/test_standard_memory.py`），4 条 failed 是缺
`DEEP_AGENT_TEST_POSTGRES_URL` / `GUIDED_RESEARCH_TEST_POSTGRES_URL`——同样是环境前置，不是行为不符合契约。

## 被卡住的验收项（在 #3003 中登记本编号）

| 能力 | 卡住的层 |
|---|---|
| WX-T001–T008（AT-T001–T008） | 行为层（`test_native_file_tools.py` 8/8 未执行） |
| WX-E003（AT-E003） | 真实闭环 + 禁网/穿越/跨用户反证（容器 lane） |
| WX-E004（AT-E004） | 渐进读取与脚本真实执行、跨组织、版本切换（容器 + 真库 lane） |
| WX-T016/T017、T027/T028 | 真数据授权/撤回/跨租户（`standard-context-source.test.ts`、`organization-context-source.test.ts`，0 条断言） |
| WX-T031/T032/T033 | CAS/墓碑/重启/租户隔离（`test_standard_memory.py` 6 skip、`standard-memory-real-db.test.ts` 未执行） |

## 建议

1. **短期**：把 B1+B2 里依赖容器/真库的层，指派到有 docker 镜像出口的 runner（CI 或人类本机），远程 agent 会话只承担 L0/L1。
2. **中期**：给 `apps/api/tests/support/db.ts` 的 `postgresReady()` 加 TCP 直连回落（见 ① 的 ⚠），让「已有 PostgreSQL」成为受支持的跑法——这条独立于镜像策略，本仓自己也用得上。
3. 本 issue 只登记阻塞与根因，**不实现**。

Read apps/api/tests/support/db.ts, especially postgresReady() and ensureDatabase(), together with apps/api/vitest.config.ts and tests/support/db-global-setup.ts. Compare the documented WORKSPACEX_REUSE_INFRA path with the existing PostgreSQL probe, then review the listed skill-sandbox and deep-agent tests. Done should be demonstrated by a supported existing-database path and by running container-dependent suites on a runner that can pull their images.

Written by the indexing model from the issue text.