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.

Begin by locating Copilot CLI's hook-loading entry point and any existing hook tests; the issue names no files or tests. Completion should provide a user- or automation-controlled opt-out for repository/workspace hooks, clearly report that they were disabled, and preserve any intended distinction for trusted hooks.

Written by the indexing model from the issue text.