运维待办：develop.boardx.us 的 Cloudflare Access 需收缩到治理面（阻塞 F02 verify）

p30/F02（GitHub OAuth 灰度）的 verification 命令 \`curl -sf https://develop.boardx.us/explore | grep -q 'explore-directory'\` 目前失败——不是代码问题，是 Cloudflare Access 应用配置还没收窄。

**现状**：\`curl -I https://develop.boardx.us/explore\` 返回 302，Location 指向 \`boardx.cloudflareaccess.com/cdn-cgi/access/login/...\`——整个域名（含公开层 /explore /projects/:slug /u/:handle /a/:handle/:agent）仍在 Cloudflare Access 门禁后面。

**设计意图**（F02 本身的实现已经就绪，`middleware.ts` 的 matcher 只含 `/me*`、`/p/*`、`/onboard`，公开层四路由代码上就是零鉴权零身份读取）：F02 落地时的约定是"Access 收缩到治理面是人类 dashboard 操作，代码侧不删任何 Access 配置"——即需要人类去 Cloudflare dashboard 把 Access 应用的保护路径从"整个域名"改窄成只覆盖 `/portal` 和 `/api/portal/*`（治理面），把 `/explore`、`/projects/:slug`、`/u/:handle`、`/a/:handle/:agent`、`/me*`、`/p/*`、`/onboard`、`/api/coord/*` 移出 Access 保护范围（工作区/个人层走的是本仓自己的 GitHub OAuth，不该依赖 Access）。

**这一步至今没有人做**，导致 F02 卡在 verify 门控，间接卡住 F03/F04 及后续所有需要打生产环境的 verify。

**需要人类做的操作**：登录 Cloudflare dashboard → Zero Trust → Access → Applications → 找到 develop.boardx.us 对应的应用 → 把保护路径改窄（或新建一个只覆盖 /portal、/api/portal/* 的应用，删掉覆盖全域名的旧应用/收窄其 path）。

不阻塞代码侧任何工作，但阻塞 harness verify 拿到 F02 passing 状态。

Start by running the listed curl verification commands and review the existing middleware.ts matcher, then inspect the develop.boardx.us application in Cloudflare Zero Trust Access. Done means public routes no longer redirect to Access, governance paths remain protected, and the F02 verification command passes.

Written by the indexing model from the issue text.