Replace azure-prepare skill Terraform remote-state backend bootstrap with a script

## Summary

Copilot has identified a portion of a skill that is a good candidate for replacement with a script.

The candidate is the **Terraform remote-state backend bootstrap** in the `azure-prepare` skill, duplicated verbatim in `references/recipes/terraform/patterns.md` ("State Backend Setup") and `references/recipes/azd/terraform.md` ("Remote state setup").

## Candidate description

Both files hand-write the same deterministic three-command sequence to provision the Azure Storage backend that holds Terraform remote state:

1. `az group create --name rg-terraform-state --location `
2. `az storage account create --name tfstate --resource-group rg-terraform-state --sku Standard_LRS`
3. `az storage container create --name tfstate --account-name tfstate`

The `azd` variant additionally wires the result into the azd environment:

4. `azd env set TF_STATE_RESOURCE_GROUP rg-terraform-state`
5. `azd env set TF_STATE_STORAGE_ACCOUNT tfstate`

This is a strong script candidate because it is:
- **Duplicated verbatim across two files** — the same three `az` commands appear in both `terraform/patterns.md` and `azd/terraform.md`, maintained independently and prone to drift.
- **Deterministic** — a fixed, idempotent sequence of resource-creation commands with no branching that requires judgment.
- **Error-prone manually** — the `` storage-account suffix is currently a hand-edited placeholder (storage account names must be globally unique and lowercase/numeric); getting it wrong fails late. A script can generate a valid unique suffix once and reuse it consistently across all three commands (and the two `TF_STATE_*` env settings).

**Sketch — `setup-tf-state.{sh,ps1}`:**
- **Input:** state resource-group name, location, storage-account name prefix; optional flag to also set the azd `TF_STATE_*` env vars.
- **Output:** a compact, self-describing result — the resolved (unique) storage account name, the created resource group/container, and (when requested) confirmation that `TF_STATE_RESOURCE_GROUP` / `TF_STATE_STORAGE_ACCOUNT` were set — so the agent does not have to invent the suffix or re-parse CLI output.

## Affected file and lines

- [`recipes/terraform/patterns.md` — "State Backend Setup" (L111–L125)](https://github.com/microsoft/GitHub-Copilot-for-Azure/blob/3890cbfb65c548ce8daa96cabd1d8de63f7bbcca/plugin/skills/azure-prepare/references/recipes/terraform/patterns.md#L111-L125)
- [`recipes/azd/terraform.md` — "Remote state setup" incl. TF_STATE_* env wiring (L282–L300)](https://github.com/microsoft/GitHub-Copilot-for-Azure/blob/3890cbfb65c548ce8daa96cabd1d8de63f7bbcca/plugin/skills/azure-prepare/references/recipes/azd/terraform.md#L282-L300)

## Next steps

1. **Evaluate the candidate** — confirm the steps are stable and parameterizable, and that the script captures everything the skill needs (including generating a valid unique storage-account suffix).
2. **Create both a bash _and_ a PowerShell version** of the script so the skill works across platforms.
3. **Run integration tests** to verify the scripts behave correctly and the skill still completes end-to-end.

## Background Information

### Why replace regular steps with scripts

Replacing a regular, well-defined series of steps with a script can:

- **Reduce token usage** — the skill no longer needs to spell out each command and parse large command output inline; the agent invokes one script and reads a compact result.
- **Improve reliability** — the logic is written and tested once, instead of being re-derived by the agent on every run.
- **Improve determinism** — the same inputs always produce the same steps and output, removing run-to-run variation.
- **Improve speed of execution** — a single script call replaces multiple round-trips of command generation, execution, and large-output parsing.

### Authoring notes for the scripts

- **Reference scripts with markdown links**, not just a bare path to the script file.
- **Include examples** in the skill showing how to run each script (sample invocation with arguments).
- **Briefly explain what each script does** where it is referenced.
- **The script output should explain what it did**, so the agent and user can understand the result without re-inspecting raw command output.