azure-prepare and azure-validate skills should cross-reference Azure Policy against planned resource configurations

## Summary

The `azure-prepare` and `azure-validate` skills should query Azure Policy assignments and cross-reference the policy effects/parameters against the specific resource configurations being generated, **before** attempting deployment.

## Problem

Currently, neither skill performs a meaningful Azure Policy check against the planned infrastructure. During a deployment of an Azure Functions app, the storage account was created with `allowSharedKeyAccess: true` (matching the framework's reference sample), but the target subscription had a policy denying local authentication methods on storage accounts. This was only caught at `azd up` time, resulting in a failed deployment and wasted provisioning cycle.

The `azure-validate` skill does have a "Policy Validation" step (step 11), and the `azure-prepare` workflow references `azure-context.md` for subscription confirmation, but neither actually inspects policy **effects and parameter constraints** against the specific resource properties being generated (e.g., storage account `allowSharedKeyAccess`, TLS version, public network access, etc.).

## Suggested Behavior

### In `azure-prepare` (Phase 1, after architecture decisions):
1. Query `policy_assignment_list` for the target subscription
2. For each resource type in the planned architecture, check if any **deny** or **audit** policies constrain specific properties (e.g., `allowSharedKeyAccess`, `minimumTlsVersion`, `publicNetworkAccess`)
3. Adjust the generated Bicep/Terraform to comply with those policies **before** writing files

### In `azure-validate` (step 11 - Policy Validation):
1. Parse the generated IaC files for resource configurations
2. Cross-reference against active deny policies on the target subscription
3. Flag any property values that would be rejected by policy
4. Fail validation with actionable guidance (which property to change and why)

## Example

Policy: *"Local authentication methods are not allowed"* on `Microsoft.Storage/storageAccounts`
Generated Bicep: `allowSharedKeyAccess: true`
Expected: Skill detects the conflict and sets `allowSharedKeyAccess: false`, adding appropriate RBAC roles for managed identity access instead.

## Impact

Without this, deployments fail at `azd provision` time with a generic `RequestDisallowedByPolicy` error, requiring manual debugging and re-deployment. Enterprise subscriptions commonly have these policies, making this a frequent friction point.