Promote policy advisor to blocking deployment gate

Compare the existing Stage 2.5 security gate pattern with the policy advisor and pipeline integration at Stage 2.85. Review copilot-instructions.md, .azure/git-ape.yml, and git-ape-plan.yml to define audit and deny behavior, override logging, and the PR summary. Done means Stage 2.55 reports PASSED or BLOCKED, deny mode blocks Critical/High findings, and the workflow comment includes policy compliance.

Description

The policy advisor skill and agent are already comprehensive — they query live subscription state, classify findings by 4-tier severity, generate remediation code (ARM JSON + CLI), and produce split reports (dev template fixes + platform subscription actions). The only structural gap is the absence of a blocking gate that prevents deployment when policy violations are found. This mirrors the existing security gate (Stage 2.5) pattern.

What already exists (no changes needed)

• ARM template policy analysis across 7 resource categories
• Live subscription policy queries (az policy assignment list, management groups)
• Microsoft Learn runtime lookup for current built-in policies
• 4-tier severity classification (Critical/High/Medium/Low) with Audit/Deny effects
• Split report: Part 1 (template fixes) + Part 2 (subscription actions)
• Auto-remediation suggestions with exact ARM JSON snippets
• Policy-as-code generation (Microsoft.Authorization/policyAssignments)
• Enforcement mode preference in copilot-instructions.md (Audit default, Deny for production)
• Pipeline integration at Stage 2.85

Scope (what's needed)

1. Stage 2.55 Policy Gate — Add a blocking gate step after the policy advisor runs, mirroring the Stage 2.5 security gate pattern:
   • 🟢 POLICY GATE: PASSED — No Critical or High policy violations. Deployment may proceed.
   • 🔴 POLICY GATE: BLOCKED — Critical or High violations found. Deployment blocked until resolved.
   • Override mechanism: user types "I accept the policy risk" (logged as OVERRIDDEN).
2. Config toggle — Formalize the existing audit/deny preference in copilot-instructions.md or .azure/git-ape.yml as a gate mode:
   • audit (default) — Policy report is generated and shown but does not block deployment.
   • deny — Policy findings at Critical/High severity block deployment (gate enforced).
3. Workflow integration — Add policy analysis summary to git-ape-plan.yml PR comment alongside security and cost sections.

Acceptance Criteria

• Policy gate step added at Stage 2.55 with PASSED/BLOCKED status.
• Gate mode configurable: audit (non-blocking) or deny (blocking).
• Deny mode blocks deployment on Critical/High policy findings.
• Override mechanism with logged justification.
• Plan workflow PR comment includes policy compliance section.