Add AKS zone-down demo sample

[Nikhil Kaul (nikhilkaul1234)]

First sample for samples/: a ~30-minute end-to-end demo that deploys the AKS store demo app to a zone-redundant AKS cluster, runs the Compute Zone Down scenario from a Workspace, and shows the app surviving the outage (and the single-replica queue degrading — the teachable moment).

What's in it

• samples/aks-zone-down-demo/README.md — demo runbook: what it shows, setup, the demo flow, cleanup
• deploy.sh / cleanup.sh — automate the app/infra half so a demo starts at the interesting part (Cloud Shell friendly, env-var overridable)
• samples/README.md — replace the scaffold note with a sample table and a per-folder contribution convention

Context

Field teams keep asking for a way to demo Chaos Studio to customers without hand-holding. This pairs with a new Learn tutorial covering the same flow in full (MicrosoftDocs/azure-monitor-docs-pr#5073); the README links to it, so that PR should merge first. The scripts stop at app deployment on purpose — the Workspace/scenario part stays in the portal, since that's the product surface being demoed (or via the Copilot CLI plugin for the conversational route).

[RenzoPrettoMS]

Review #1 — PR #28 "Add AKS zone-down demo sample"
Merge readiness: ⚠️ Needs minor fixes
Review confidence: 73/100 🟡 · Strictness: Level 2 (Standard)
Deliberation: 1 round, full consensus (no disputes), 0 critical / 4 warnings
Models: claude-opus-4.7 (Security & Correctness), gpt-5.5 (Robustness & Completeness)
4 consensus findings (all 🟡)
deploy.sh:9 — MANIFEST_URL tracks upstream main and is piped to kubectl apply unpinned → supply-chain + drift risk. Pin to a commit SHA/tag with env override.
cleanup.sh:11 — az group delete --yes --no-wait runs unconditionally on ${RESOURCE_GROUP:-chaos-demo-rg}, no confirmation/ownership check → can silently wipe a pre-existing group. Add a tag-ownership guard + typed confirmation unless FORCE=1.
README.md:90 — the "fix" step scales store-front to 3 replicas without a zone topology spread constraint → scheduler may co-locate replicas, making the zone-resilience "proof" nondeterministic. Add topologySpreadConstraints on topology.kubernetes.io/zone.
deploy.sh:27 — script waits only for the LoadBalancer IP, not rollout readiness → setup can report success before the app is Ready. Add kubectl rollout status deployment/store-front --timeout=5m.

[Nikhil Kaul (nikhilkaul1234)]

All four automated findings addressed in 1695f35, plus the permissions rewording from the inline thread:

• Manifest pinning: MANIFEST_URL now pins to the aks-store-demo 2.2.0 release and is env-overridable.
• cleanup.sh guard: deploy.sh tags the resource group (chaos-demo=aks-zone-down-demo); cleanup.sh refuses to delete a group without that tag and requires typing the group name to confirm (skippable with FORCE=1).
• Deterministic fix step: the demo's fix is now kubectl patch adding replicas: 3 plus a topologySpreadConstraints on topology.kubernetes.io/zone, so the zone spread is guaranteed rather than left to scheduler luck. Used ScheduleAnyway so replacement pods aren't left pending during the actual zone-down run. This also makes the teaching point sharper: replicas alone aren't the fix, spreading them is.
• Rollout readiness: deploy.sh waits on kubectl rollout status deployment/store-front before waiting for the IP.

The Learn tutorial (MicrosoftDocs/azure-monitor-docs-pr#5073) got the matching permission-flow, pinning, and spread-constraint changes. Ready for another look.