Enterprise MCP allowlist tool schemas exceed runtime token limit → persistent compaction loop

### Describe the bug

# Copilot CLI Feedback Draft

## Short version (paste this if /feedback has a length limit)

**Bug: Enterprise MCP allowlist exceeds hard-coded token limit, causing infinite compaction loop**

CLI v1.0.54, Windows. Two experiment flags in my config.json are enabled:
- `copilot_cli_mcp_allowlist: true`
- `copilot_cli_mcp_enterprise_allowlist: true`

These auto-load ~13 enterprise MCPs (kusto, sharepoint, mail, calendar, m365-copilot, icm, enghub, graph, github-mcp-server, workiq, teams, onedrive, msft-learn). Their tool schemas alone (~573K tokens) far exceed the ~136K runtime token limit.

Result: truncation + compaction fire every single turn. Current session: 4 compaction_start / 3 compaction_complete / 1 truncation events in 4 user turns. Sessions become unusable - compaction interrupts answers and produces empty summaries (the "looping issue").

My settings.json has `contextTier: long_context` and model `claude-opus-4.7-1m-internal`, but the runtime ignores `contextTier` and applies the ~136K cap anyway.

I cannot fix this locally:
- Trimming my mcp-config.json has no effect (enterprise allowlist is server-side)
- contextTier is ignored
- Hard limit is in the binary

**Requested fix (any one of these would resolve it):**
1. Honor `contextTier: long_context` in the runtime token budget
2. Allow users to opt out of `copilot_cli_mcp_enterprise_allowlist` locally
3. Lazy-load enterprise MCP tool schemas only when invoked instead of upfront
4. Raise the hard-coded token limit to match the model's actual context window

---

## Long version (if /feedback opens a form/editor with no length cap)

**Title:** Enterprise MCP allowlist tool schemas exceed runtime token limit -> persistent compaction loop

**CLI Version:** 1.0.54
**Model:** claude-opus-4.7-1m-internal (1M context advertised)
**OS:** Windows_NT
**Settings:** contextTier=long_context, effortLevel=xhigh

**Reproduction (100% in my environment):**
1. Open any new CLI session
2. Send any short user turn
3. Observe events.jsonl: compaction_start fires immediately
4. Within 4 turns: 4 compaction_start events, 3 completes, 1 truncation, multiple warnings
5. Assistant responses get interrupted mid-tool-call by compaction and frequently produce empty summaries, looping the session

**Root cause (from local diagnosis):**
- config.json shows two experiment flights enabled:
- copilot_cli_mcp_allowlist: true
- copilot_cli_mcp_enterprise_allowlist: true
- These cause auto-load of ~13 enterprise MCPs (kusto, sharepoint, mail, calendar, m365-copilot, icm, enghub, microsoft-graph, github-mcp-server, workiq, teams, onedrive, msft-learn)
- Combined tool schemas measured at ~573K tokens
- Runtime applies a hard-coded ~136K token limit regardless of contextTier setting
- 573K >> 136K, so truncator + compaction fire on every turn from turn 0

**What I tried (none worked):**
- Trimmed local mcp-config.json to azure-devops + filesystem only (1158 bytes) - no effect, enterprise list is independent
- Set contextTier: long_context in settings.json - ignored by runtime
- Updated to latest CLI (already on 1.0.54)
- Switched to 1m-internal model - runtime token limit unaffected

**Impact:** CLI is effectively unusable for any non-trivial multi-turn task on Microsoft tenant accounts that have this flight enabled. Every session degrades within a few turns.

**Suggested fixes (in order of preference):**
1. Have the runtime honor `contextTier: long_context` and scale the token budget to the model's actual context window
2. Provide a documented local setting (e.g., `disableEnterpriseMcpAllowlist: true`) to opt out
3. Lazy-load MCP tool schemas - only inject a server's tool definitions when the model first calls one, instead of all upfront
4. Raise the hard-coded ~136K cap

**Why this is urgent:** This isn't a personal config problem - it's an interaction between a rolled-out experiment flight and a runtime constant. Every user enrolled in `copilot_cli_mcp_enterprise_allowlist` on a tenant with a large allowlist will hit this. The fix has to come from the CLI team; users cannot work around it.

Happy to share config.json, settings.json, events.jsonl from the failing session if useful.

### Affected version

_No response_

### Steps to reproduce the behavior

_No response_

### Expected behavior

_No response_

### Additional context

_No response_

Start by reproducing the issue with the enterprise MCP allowlist enabled and inspect events.jsonl for compaction_start, compaction_complete, and truncation events. Read the handling of contextTier, enterprise allowlist loading, and the runtime token budget; done means sessions no longer repeatedly compact or truncate when the reported configuration is used.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.