Copilot exfiltration protection is too agressive and block legitimate spec content.

### Describe the bug

I have a spec file that contains the following line

```
- Rover's `supergraph.yaml` supports Router-style variable expansion (e.g. `Authorization: "Bearer ${env.AUTH_TOKEN}"`), so the token can be injected via an environment variable at compose time without hand-editing the config file per run.
```

The security feature redact the `Bearer ${env.AUTH_TOKEN}`, to `******` causing agent to get confused.

That's really not ideal. It prevent reading completely valid specification. As you can see, no actual secret are being exfiltrated.

I understand why the feature exists, clearly the PII protection should be on by default but it would be nice to be able to configure the level of redaction. Certain type of task demand that we edit Authorization Header code, it is part of programming. The current security settings make this impossible.

That's quite blocking for my current work

### Affected version

GitHub Copilot CLI 1.0.69

### Steps to reproduce the behavior

Use plan mode or similar to create a markdown file containing specification on how to construct an Authorization Header
In a fresh session, ask the agent to review the file and see if there is ambiguities

The agent will complain about the ******. Sometime he will be smart about it and use xxd to read the ****** , meaning the secrets aren't really protected.

### Expected behavior

With a precise, not on by default workaround, the agent can be made to see the full specification so he can review the file and work on it.

### Additional context

_No response_

Reproduce the behavior in GitHub Copilot CLI 1.0.69 by asking the agent to review a markdown specification containing the Authorization header example. Start by tracing the exfiltration or PII redaction behavior and its configuration surface. Done means a precise, opt-in workaround lets the agent read legitimate specification content without weakening protection by default.

由索引模型根據 Issue 內容生成。