[quickstart] Add Chaos Studio v2 AzAPI quickstarts (Microsoft.Chaos 2026-08-01-preview)

[Cristian Velez (kekivelez)]

Summary

Adds/updates two Terraform quickstarts for Azure Chaos Studio v2, expressed with
the AzAPI provider
against Microsoft.Chaos 2026-08-01-preview:

Quickstart	What it shows
quickstart/101-chaos-studio-workspace-azapi	Minimal getting-started: a resource group and a Microsoft.Chaos/workspaces with a scope and a managed identity. No fault is injected.
quickstart/201-chaos-studio-scenario-run-azapi	End-to-end: target infrastructure, a Reader role assignment, a ScenarioConfiguration, and the discover -> evaluate -> validate -> fixResourcePermissions -> execute action chain.

Microsoft.Chaos v2 is a preview api-version with no typed azurerm
resource, so AzAPI is how customers reach it. Native azurerm support, when it
lands, is additive - it does not replace these examples.

The 201 never injects a fault unless the operator opts in: var.execute_scenario
defaults to false, so an unattended apply/destroy (including this repo's
weekly main-branch E2E) provisions, discovers, validates, and previews the
permission fix, then stops.

Provider and Terraform pins

Component	Constraint in providers.tf	Version this PR was validated on
Terraform	>= 1.5	1.9.8
Azure/azapi	~> 2.0 (>= 2.11.0)	2.12.0
hashicorp/azurerm	~> 4.0	4.81.0
hashicorp/random	~> 3.0	3.9.1

Live validation

Both quickstarts were applied against a real subscription, asserted, and
destroyed before this PR was opened. Evidence comes from a
chaos-tf-live-evidence/v1 record written by the quality-gate runner, not from
a hand-written note.

Field	Value
Subscription class	ChaosRP internal test subscription (corp tenant)
Region	westus2
Api-version	2026-08-01-preview (spec pin services/GW/src/ArmGatewayService/openapi-baselines/2026-08-01-preview.json (sha256:6b51400dcd6a))
101 apply -> outputs -> destroy	PASS
201 apply -> workflow -> destroy (with execute_scenario = true)	PASS
ScenarioConfiguration validation state observed by the 201 run	RequiresAttention
Terminal ScenarioRun state observed by the 201 run	Succeeded

What each run asserted:

• 101 - the workspace id and the workspace identity principal id are
  non-empty, and destroy leaves nothing in state.
• 201 - the above plus the ScenarioConfiguration id, an accepted
  validation state (Succeeded or RequiresAttention), a permission-fix
  state, and - on the opted-in executing path - a terminal ScenarioRun
  state. RequiresAttention is expected for this example because validation
  runs before fixResourcePermissions against a newly created identity.

The run state above is the state the run actually reached, not Canceled.
The execute action's long-running operation is polled to a terminal state
before apply returns, so by the time terraform destroy runs the
when = "destroy" cancel action has nothing left to cancel and is a no-op.
destroy completing cleanly with an empty state - and no fault left on the
target - is the observable evidence for that action, and it is what was
recorded. The 201 readme documents the interrupted-apply case (where the
cancel action cannot help) and the manual remediation for it.

No live test runs on this pull request itself: this repo's E2E workflow skips
forked pull requests. The weekly scheduled main-branch E2E re-proves the
examples after merge and maintains TestRecord.md on the default branch.

Static validation

Every commit to these examples is gated in the source repository by
terraform fmt -check, terraform init -backend=false + terraform validate,
tflint (bundled terraform ruleset), a conformance check that every
Microsoft.Chaos type, action, and request-body key used by the HCL exists in
the pinned spec, and a zero-diff drift check against the generated api-version
block in main.tf.

---

_{This PR was prepared from kekivelez/terraform:users/kekivelez/chaos-codegen-20260911-005606-af702637d/tf-examples by the
chaos-automation-codegen skill.}