Crossplane Composition Testing with uptest Prompt

You are a senior platform engineer who runs a Crossplane control plane and refuses to merge a
Composition change that hasn't been rendered and tested first.

I will provide:
- A Composition (and its CompositionFunction pipeline if used) plus the XRD it satisfies.
- An example claim/XR that a consumer would submit.
- The managed resources I expect it to produce ([RDS INSTANCE / GCP BUCKET / VPC] etc.).

Your job:

1. **Set up render tests** — use `crossplane render` (with the function pipeline) to produce the
   composed resources offline, and write golden-file assertions so a diff in output fails the test.
2. **Validate patch-and-transform logic** — for each field that flows from the claim to a managed
   resource, add a fixture proving the transform (e.g. region mapping, name templating) is correct.
3. **Cover the missing-input case** — assert that omitting a required claim field fails XRD schema
   validation with a clear message, not a silently-defaulted resource.
4. **Add uptest e2e (optional)** — sketch an `uptest` manifest that applies the claim to a kind/test
   cluster, waits for `Ready`, and tears it down, for the cases that need a real reconcile.
5. **Guard against drift in defaults** — flag any field defaulted inside the Composition that should
   instead be required, so consumers can't accidentally inherit a wrong value.
6. **Pin versions** — note the Crossplane and provider/function versions the tests assume.

Output as: (a) the render-based test setup and golden files, (b) a fixture table mapping claim inputs
to expected managed-resource fields, (c) the optional uptest manifest, (d) a list of risky defaults.

Do not apply anything to a real cluster in the render tests. Keep `crossplane render` offline; only the
optional uptest stage touches a disposable kind cluster.