Clarify/support .copilotignore semantics in Copilot CLI

### Summary

Please clarify and/or support `.copilotignore` semantics in Copilot CLI, especially for nested ignore files.

Related but broader issue: https://github.com/github/copilot-sdk/issues/963 asks for general `.copilotignore` support. This issue is specifically about the expected behavior in Copilot CLI and whether it should match the public VS Code Copilot Chat implementation.

### Existing public reference point

VS Code Copilot Chat has a public `.copilotignore` implementation:

- `COPILOT_IGNORE_FILE_NAME = '.copilotignore'` in `ignoreServiceImpl.ts`:
https://github.com/microsoft/vscode-copilot-chat/blob/main/src/platform/ignore/node/ignoreServiceImpl.ts#L23
- `IgnoreFile` uses the `ignore` npm package and `@humanwhocodes/gitignore-to-minimatch`, making the syntax intentionally gitignore-like:
https://github.com/microsoft/vscode-copilot-chat/blob/main/src/platform/ignore/node/ignoreFile.ts

The VS Code implementation appears to:

1. Track multiple `.copilotignore` files in a workspace.
2. Scope each ignore file to its own directory/subtree.
3. Sort ignore files deepest-first.
4. For a target path, check the deepest applicable ignore file first and stop when that file produces either an ignored or unignored result.

That is similar to gitignore-style scoped files, but it is not obviously the same as Git's full cascading merge semantics. It is closer to "nearest/deepest applicable `.copilotignore` wins when it has a matching ignore/unignore rule; otherwise broader files may still be checked."

### Problem

For Copilot CLI, the behavior is unclear:

- Does Copilot CLI support `.copilotignore` files at all, or only managed organization/repository content-exclusion policies?
- If `.copilotignore` is supported, should it match the VS Code Copilot Chat implementation linked above?
- Are multiple nested `.copilotignore` files discovered?
- Is each file scoped to its directory/subtree?
- Are patterns relative to the ignore file location or the repository/workspace root?
- How do negation patterns (`!foo`) interact across parent/child ignore files?
- Does the same exclusion decision apply consistently to file discovery, `@` file mentions, read/search tools, context loading, and edit targets?

This matters because users may assume `.copilotignore` behaves like `.gitignore`, place scoped files in nested directories, and then accidentally expose or allow edits to content they expected Copilot to ignore.

### Desired outcome

Please either:

1. Document that Copilot CLI supports `.copilotignore` and define its nested-file semantics, ideally aligning with VS Code Copilot Chat where possible; or
2. Document that Copilot CLI does not support `.copilotignore` and users should use managed content-exclusion policies instead; or
3. Add support/parity with VS Code Copilot Chat's public `.copilotignore` behavior.

### Environment

Observed while investigating Copilot CLI 1.0.61 behavior.

Start by reproducing the reported Copilot CLI 1.0.61 behavior with nested `.copilotignore` files and compare it with the linked VS Code Copilot Chat implementation. Trace how file discovery, `@` mentions, read/search tools, context loading, and edit targets apply exclusions. Done means the project documents or implements a consistent, tested decision for nested files, scoping, patterns, and negation.

Vom Indexierungsmodell aus dem Issue-Text verfasst.