Managed settings policy fetch fails closed on valid enum value "enable" for permissions.disableBypassPermissionsMode, blocking ALL local/custom MCP servers

[ModelkinIY]

Describe the bug

On startup, the CLI fetches the enterprise managed-settings policy from our GHE instance. The
fetch fails schema validation because permissions.disableBypassPermissionsMode is returned as
"enable", but the CLI's validator only accepts the literal "disable" as a valid enum value.

Because the fetch fails, the CLI "fails closed": it then blocks every non-built-in MCP server
configured in ~/.copilot/mcp-config.json, including our two local project MCP servers and even
the official github-mcp-server. Only the IDE's own built-in MCP connection still works.

Notably, VS Code's native MCP client (.vscode/mcp.json, used by Copilot Chat in the editor)
connects to the exact same two local MCP servers without issue against the same enterprise
account — so this looks specific to the standalone CLI's managed-settings parser, not a real
policy restriction from the enterprise side.

Affected version

GitHub Copilot CLI 1.0.77 (checked 1.0.78-2 changelog too — no related fix mentioned)

Steps to reproduce

1. Authenticate against a GHE Enterprise Cloud/Server host whose managed Copilot policy sets
   permissions.disableBypassPermissionsMode to "enable" (rather than "disable").
2. Configure any local/custom MCP server in ~/.copilot/mcp-config.json (type: "local").
3. Start copilot in a repo with that config.
4. Observe in ~/.copilot/logs/process-*.log:

```
[WARNING] [managedSettings] server policy fetch failed — failing closed: [fetchManagedSettings] Unexpected response format: permissions.disableBypassPermissionsMode: Invalid enum value. Expected 'disable', received 'enable'
[ERROR] Skipping MCP server "": not permitted by enterprise managed allow list
```

Expected behavior

• disableBypassPermissionsMode enum should accept both "enable" and "disable" (matching
  whatever the managed-settings backend actually emits), OR
• If the enum truly should only ever be "disable", the backend/schema mismatch needs to be
  fixed so the two are in sync.
• A malformed/unrecognized field in managed settings should not silently deny all MCP servers
  without any actionable remediation guidance in the CLI's user-facing output (currently only
  visible in the raw process log, not surfaced to the user in the TUI).

Additional context

Log excerpt:
```
2026-08-03T16:01:54.870Z [INFO] [managedSettings] effective policy resolved: source=none, bypassDisabled=false, serverFetchFailed=true
2026-08-03T16:01:54.870Z [WARNING] [managedSettings] server policy fetch failed — failing closed: [fetchManagedSettings] Unexpected response format: permissions.disableBypassPermissionsMode: Invalid enum value. Expected 'disable', received 'enable'
2026-08-03T16:01:55.123Z [ERROR] Skipping MCP server "umacs-build-bridge": not permitted by enterprise managed allow list
2026-08-03T16:01:55.123Z [ERROR] Skipping MCP server "umacs-dev-bridge": not permitted by enterprise managed allow list
2026-08-03T16:01:55.146Z [ERROR] Skipping MCP server "github-mcp-server": not permitted by enterprise managed allow list
```

Enterprise host: GitHub Enterprise Server/Cloud (custom *.ghe.com tenant).