[Bug] kms_protection_level is required by four FAST stages but is set by nothing, and 0-bootstrap builds its keys from the raw variable instead of the regime-aware local it computes

## Bug Description

`v3.0.0` made the KMS protection level configurable for FedRAMP Moderate. The variable was added to
four stages, and a regime-aware default was written — but the default is never used, and the variable
is never supplied.

**1. Stage 0 computes the right default and then ignores it.**

```
# fast/stages-aw/0-bootstrap/main.tf:39
kms_protection_level = coalesce(var.kms_protection_level,
var.assured_workloads.regime == "FEDRAMP_MODERATE" ? "SOFTWARE" : "HSM")
```

`local.kms_protection_level` is referenced nowhere else in the stage. The keys are built from the
variable directly:

```
# fast/stages-aw/0-bootstrap/kms.tf:15-20
locals {
version_template = {
algorithm = "GOOGLE_SYMMETRIC_ENCRYPTION"
protection_level = var.kms_protection_level
}
}
```

At `v2.13.0` the same lines read `protection_level = "HSM"`, unconditionally.

**2. The variable has no default and no source.** `0-bootstrap/variables.tf:228` declares it
`nullable = true` with **no `default`**, so Terraform prompts for it. It does not appear in
`terraform.tfvars.sample`, and `docs/ddg.md` never mentions it, so an operator following the
deployment guide has nothing telling them the value exists.

**3. Stage 0 does not pass it on, and three more stages require it.** `outputs.tf` exposes a
standalone `output "kms_protection_level"`, but the value is in neither `local.tfvars` nor
`local.tfvars_globals` — the two maps that become the `.auto.tfvars.json` files the later stages
consume. Meanwhile `1-resman/variables.tf:259`, `2-networking-a-fedramp/variables.tf:239` and
`3-security/variables.tf:192` each declare `kms_protection_level` with no default and no
`tfdoc:variable:source` annotation. Each of those stages therefore stops and prompts as well.

The net effect on a documented deployment is four interactive prompts for a variable the guide does
not describe. Pressing Enter supplies `""`: in Stage 0 the unused `coalesce` cannot save it, because
`kms.tf` reads the variable, so `""` reaches the key. Supplying `null` produces the same result the
other way — the organization's logging and GCS keys are created **without HSM protection on a
FedRAMP High deployment**, which is the case the hardcoded `"HSM"` used to guarantee.

## Environment and Deployment Context
* **Stellar Engine Version/Commit:** `main` @ `6d7d08c0` (2026-09-09); introduced in `v3.0.0` (`f64ce6cd`) by PR #162. At `v2.13.0` (`8f5b67a6`) `0-bootstrap/kms.tf:18` is `protection_level = "HSM"` and no stage declares the variable.
* **Deployment Type:**
* [ ] US Region Restricted (e.g., Access Policy constraint)
* [x] FedRAMP Moderate
* [x] FedRAMP High
* [x] DoD IL4
* [x] DoD IL5
* [ ] Stand-alone / Custom
* **FAST Stage (if applicable):** all four
* [x] Stage 0 (Bootstrap)
* [x] Stage 1 (Resource Management)
* [x] Stage 2 (Networking)
* [x] Stage 3 (Security)

## Steps to Reproduce
1. Follow `docs/ddg.md` to prepare `fast/stages-aw/0-bootstrap/terraform.tfvars` from `terraform.tfvars.sample`, with `assured_workloads.regime = "FEDRAMP_HIGH"`.
2. `terraform plan`. Terraform prompts: `var.kms_protection_level — Enter a value:`.
3. Press Enter. Inspect the planned `google_kms_crypto_key` resources in the log-export project: `version_template.protection_level` is `""`, not `HSM`.
4. Continue to Stage 1, Stage 2 and Stage 3. Each prompts for the same variable, because it is in neither `.auto.tfvars.json` Stage 0 generates.

## Expected Behavior
A FedRAMP High deployment that follows the deployment guide produces HSM-protected keys with no prompt, exactly as it did at `v2.13.0`. A FedRAMP Moderate deployment gets `SOFTWARE` from the regime, or from one explicit setting. Downstream stages inherit the value from Stage 0's outputs like every other shared value.

## Actual Behavior
Four prompts for an undocumented variable; an empty answer silently degrades the organization's KMS protection level on a FedRAMP High deployment.

## Relevant Logs and Errors
```
var.kms_protection_level
KMS protection level.

Enter a value:
```

## Additional Context
* Suggested fix, three small changes: (1) `kms.tf` uses `local.kms_protection_level` instead of `var.kms_protection_level`, so the regime default applies; (2) add `kms_protection_level` to `local.tfvars` in `0-bootstrap/outputs.tf` and mark the downstream declarations `# tfdoc:variable:source 0-bootstrap`; (3) add a commented line to `terraform.tfvars.sample` and a row to the DDG variables table.
* A `default = null` on the four declarations would remove the prompts on its own, but on its own it would also make the FedRAMP High degradation silent rather than interactive — (1) is the part that matters.
* Related: PR #212 (`ec82b554`) made `3-security` apply this variable to keys that set no `version_template`, which is the fix for #107. That change is correct and is not affected by this report; it inherits the same unset value.

Start with fast/stages-aw/0-bootstrap/main.tf, kms.tf, variables.tf, and outputs.tf, then inspect the kms_protection_level declarations in stages 1-resman, 2-networking-a-fedramp, and 3-security. Run the documented Stage 0 plan for a FedRAMP High and Moderate regime; done means no prompts, correct regime-aware key protection, and the value is available to downstream stages.

Written by the indexing model from the issue text.