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

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 feat(provision): prompt to cancel Azure deployment on Ctrl+C (Bicep) #7795) remains as-is until the refactor lands.