Copilot App 1.1.8 still gated by org "Copilot CLI" policy despite "GitHub Copilot app" policy being Enabled

### Short summary

GitHub Copilot app 1.1.8 is still blocked by the org **Copilot CLI** policy, even though the **GitHub Copilot app** policy is Enabled and the policy text says the CLI policy stops governing the app at 1.1.

### Affected version or release

GitHub Copilot app `1.1.8` (macOS, arm64) — bundled engine `~/Library/Caches/github-copilot-sdk/cli/1.0.79-9/copilot`

### Installation context

Organization on an enterprise plan (redacted as `` below). Affects all members whose Copilot seat comes only from that org.

Policy state:
- **GitHub Copilot app** = `Enabled` (enterprise-enforced)
- **Copilot CLI** = `Disabled` (org-level)

### What happened?

The org-level policy UI for **GitHub Copilot app** states:

> If enabled, members of this organization can use the GitHub Copilot app. Enforcement begins July 27th, 2026 in version 1.1 of the GitHub Copilot app. The Copilot CLI policy continues to govern the GitHub Copilot App until version 1.1

We are on app 1.1.8, past that cutover, with the app policy Enabled. Members still cannot use the app at all — the model list fails on startup and every prompt is rejected.

Model list:

```
Failed to list models: RPC error -32603: Request models.list failed with message: 403 "unauthorized: not authorized to use this Copilot feature\n"
```

Any prompt:

```
You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled.
Request ID: 813D:3FB9FB:48AA19:54AD00:6A7E2287
```

App log:

```
ERROR github_app::handlers::misc: failed to list models
error=RPC error -32603: Request models.list failed with message:
403 "unauthorized: not authorized to use this Copilot feature\n"
```

**The app's own gate passes — its engine's does not.**

1. The app binary's `CopilotUserResponse` struct parses `copilot_app_enabled` and does **not** contain `cli_enabled`, so the app itself correctly implements the documented ≥1.1 behavior.
2. The app spawns the Copilot CLI as its engine:
```
~/Library/Caches/github-copilot-sdk/cli/1.0.79-9/copilot --server --stdio --no-auto-update
```
3. The failure surfaces as an **RPC error from that subprocess** (`RPC error -32603: Request models.list`) — so it is the engine's own API call that receives the 403, and that call is still being evaluated against the CLI policy.

Net effect: `copilot_app_enabled: true` has no practical effect while `cli_enabled: false`.

`GET https://api.github.com/copilot_internal/user` for an affected member:

```json
{
"cli_enabled": false,
"copilot_app_enabled": true,
"copilot_plan": "enterprise",
"organization_login_list": [""]
}
```

### Steps to reproduce

1. In an organization on an enterprise plan, set **GitHub Copilot app** = `Enabled` and **Copilot CLI** = `Disabled`.
2. As a member whose Copilot seat comes only from that org, sign in to GitHub Copilot app 1.1.8.
3. Observe the model picker fail with `Failed to list models: RPC error -32603: ... 403 "unauthorized: not authorized to use this Copilot feature"`.
4. Send any prompt (e.g. `say hi`) — observe `You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled.`
5. Confirm the split via `GET https://api.github.com/copilot_internal/user`: `copilot_app_enabled: true`, `cli_enabled: false`.

### Expected behavior

At app version ≥ 1.1, the **GitHub Copilot app** policy alone should govern the app, per the policy UI text. With `copilot_app_enabled: true`, both the app and the engine it spawns on the user's behalf should be authorized, and `cli_enabled: false` should not block it.

Concretely: requests the app makes through its bundled `copilot --server --stdio` engine should be evaluated against `copilot_app_enabled`, not `cli_enabled`.

The only workaround today is to enable the **Copilot CLI** org policy — which defeats the purpose of the two policies being separate, and forces admins to permit standalone terminal CLI use in order to allow the desktop app.

### Additional context

- OS: macOS (Darwin), arm64
- Org plan: enterprise
- Request ID: `813D:3FB9FB:48AA19:54AD00:6A7E2287`
- Org name redacted as ``.
- Originally filed against the CLI repo before identifying this as app-side policy resolution: https://github.com/github/copilot-cli/issues/4481

**Possibly related — entitlement resolving across enterprise boundaries**

While diagnosing this, an org owner with a Copilot seat in a *second, unrelated* organization was unaffected. Their `copilot_internal/user` returned `cli_enabled: true` with:

```json
"organization_login_list": ["", ""]
```

`` enforces its own SAML SSO (so it belongs to a different enterprise), and the token used was not SSO-authorized for it. [The policy docs](https://docs.github.com/en/copilot/concepts/policies) scope least-restrictive resolution to *"multiple organizations in the same enterprise"*. If that resolution spans enterprises, an admin cannot enforce a Copilot policy on any user holding a seat elsewhere. Noted here for visibility; being raised separately with Support.

首先检查 app 二进制文件对 CopilotUserResponse 的处理，以及报告中所述的捆绑 copilot --server --stdio 引擎路径。使用所述的策略设置，通过 GET /copilot_internal/user 和 app 1.1.8 重现这一分离；完成标准是 app 请求由 copilot_app_enabled 授权，而不要求 cli_enabled。

由索引模型根据 Issue 内容生成。