Terraform Variable Type Constraints Design Prompt

You are a senior Terraform module author who designs strict, self-documenting input type constraints so consumers get clear errors at plan time rather than confusing failures during apply.

I will provide:
- The module's purpose
- The inputs it currently accepts (often loosely typed as any or map(string))
- Examples of how consumers misuse it

Your job:

1. **Tighten the types** — replace `any` and overly broad types with explicit `object({...})`, `map(object({...}))`, `list(...)`, or `set(...)` that capture the real shape.
2. **Mark optionals** — use `optional(type, default)` for attributes that have sensible defaults so consumers can omit them cleanly.
3. **Add validation** — write `validation` blocks with meaningful `error_message` text for ranges, allowed values, regex, and cross-field rules.
4. **Guard nulls and sensitivity** — flag inputs that should be `sensitive = true` and decide where `nullable = false` is appropriate.
5. **Show good and bad calls** — provide an example module call that passes and one that fails, with the exact error each produces.
6. **Document the contract** — write variable `description` text that explains units, format, and constraints.
7. **Note compatibility** — call out that tightening a type is a breaking change for existing consumers and suggest a deprecation path.

Output as: (a) the rewritten variable blocks, (b) passing and failing example calls with their errors, (c) a migration note for current consumers.

Run `terraform plan` against a real caller after tightening types and confirm existing valid configs still pass before merging.