Add an option to disable repository hooks to reduce config-injection risk

### Problem

Repository-provided hook configuration can become a supply-chain execution surface when a repository is compromised.

SafeDep recently documented the Miasma worm campaign, where malicious commits added project configuration for multiple developer tools and used auto-run hook/task mechanisms to execute a payload when a developer opened or started an AI coding agent in the repository:

https://safedep.io/miasma-worm-ai-coding-agent-config-injection/

The relevant pattern is that the attacker did not need to compromise the agent binary. They only needed to land repository configuration such as `.claude/settings.json` / `.gemini/settings.json` hooks, editor tasks, or agent instructions that cause local code execution. A similar class of risk exists for any agent that automatically trusts repository-provided hook configuration.

### Request

Please add a first-class way for users and automation to disable repository/workspace hooks in Copilot CLI.

Examples of possible UX:

```bash
copilot --disable-hooks
copilot --disable-repository-hooks
copilot --no-hooks
```

or an environment/configuration option such as:

```bash
COPILOT_DISABLE_HOOKS=1
COPILOT_DISABLE_REPOSITORY_HOOKS=1
```

The important property is that users and CI systems should be able to start Copilot CLI in a mode where hooks from the checked-out repository are not loaded or executed.

### Why this matters

Hooks are useful for policy enforcement and local automation, but repository-controlled hooks can also be abused as a persistence/execution mechanism after a source repository compromise. In the Miasma case, the attacker used developer-tool configuration injection to run a payload on clone/open/session start.

A user may want to inspect or remediate an untrusted repository with Copilot CLI without allowing that repository to execute hook code first.

This is especially important for:

- Incident response on potentially compromised repositories
- Reviewing third-party or newly cloned repositories
- CI or automation that runs Copilot CLI on untrusted branches/forks
- Enterprise environments that want hooks only from trusted user/org policy, not from arbitrary repo contents

### Prior art

Other AI coding tools have options to suppress or disable hooks / project-provided automation. Copilot CLI should provide an equivalent safety switch so users can opt out of repository hooks when the repository is not yet trusted.

### Desired behavior

When the option is set:

- Repository/workspace hooks should not be loaded or executed.
- The CLI should clearly log or display that repository hooks were disabled by user choice.
- Ideally, trusted user-level or enterprise-managed hooks could still be allowed separately, if that distinction exists in the hook loader.

### Related context

There are existing hook-related issues where missing hook enforcement is treated as a security problem, for example hooks not loading in some modes or subagents bypassing hooks. This request is the complementary control: users also need a deliberate, explicit way to *not trust repository-provided hooks* when working with untrusted code.

Bắt đầu bằng cách xác định entry point tải hook của Copilot CLI và mọi bài test hook hiện có; issue không nêu tên file hay test nào. Phần hoàn thiện cần cung cấp tùy chọn opt-out do người dùng hoặc automation kiểm soát cho các hook của repository/workspace, thông báo rõ rằng chúng đã bị vô hiệu hóa và giữ nguyên mọi phân biệt dự kiến dành cho các hook đáng tin cậy.

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