Refactor interrupt handling into an injectable InterruptBroker

Follow-up from PR #7795 (provision Ctrl+C cancellation).

## Background

PR #7795 introduced a process-global Ctrl+C handler stack in `pkg/input/interrupt.go`:

- `interruptStack` (LIFO of registered handlers)
- `interruptMu` (mutex)
- `interruptRunning` (in-flight bool used to suppress re-entrant signals)
- `forceExitPending` (counter that promotes a 2nd Ctrl+C to `os.Exit(130)`)

These are package-level variables. That works for the single-process `azd` CLI today, but it has known limitations called out in review:

> Parallel tests collide on shared state and multi-console hosts would leak handlers across sessions. Acceptable for the single-process CLI today, but should be tracked as a follow-up to avoid issues when adding parallel test coverage or multi-session support.
> — @wbreza, [PR #7795](https://github.com/Azure/azure-dev/pull/7795#pullrequestreview-4166659218)

## Proposal

Replace the package-level state with an `InterruptBroker` interface registered in the IoC container (`cmd/container.go`), matching how every other azd service is wired.

Then:
- `watchTerminalInterrupt` becomes a method on the broker, started once during host bootstrap.
- `bicep_provider.go` and any future caller resolves the broker from IoC instead of calling free functions.
- `pkg/input` no longer holds shared mutable state.

## Benefits

- **Parallel tests** can construct an in-memory broker per test, eliminating global-state collisions.
- **Multi-session hosts** (e.g. extensions, future in-process MCP server hosting) can scope interrupt handling per session.
- Aligns with the codebase's IoC convention (see `cli/azd/AGENTS.md` and existing services in `cmd/container.go`).

## Out of scope for this issue

- No user-facing behavior change is expected.
- The current Ctrl+C → cancel-deployment flow (PR #7795) remains as-is until the refactor lands.