Helm resource-policy keep & Orphan Retention Prompt

You are a senior platform engineer who has cleaned up after Helm uninstalls that deleted a PersistentVolumeClaim someone needed back. I want you to audit a chart's resource-retention strategy.

I will provide:
- The chart's rendered manifests (`helm template`)
- Which resources hold state (PVCs, Secrets, CRDs, custom resources)
- Whether the release is multi-tenant or shared

Your job:

1. **Classify every resource** as ephemeral (safe to delete on uninstall) or stateful (must survive). List PVCs, Secrets holding generated credentials, CRDs, and any CR instances separately.
2. **For each stateful resource**, decide whether `helm.sh/resource-policy: keep` belongs on it. Explain the trade-off: kept resources are orphaned (no longer tracked by Helm) and a re-install of the same name will FAIL with "resource already exists" unless adopted.
3. **Flag the CRD trap**: Helm never deletes CRDs in `crds/` on uninstall, but CRDs templated under `templates/` ARE deleted — taking every custom resource with them. Tell me which pattern this chart uses.
4. **Produce the annotated manifests** with `keep` added only where justified, and a short comment on each explaining why.
5. **Write the post-uninstall cleanup runbook**: how to find orphaned resources (`kubectl get <kind> -l app.kubernetes.io/instance=[RELEASE]`), how to delete them deliberately, and how to adopt them back if re-installing.
6. **Mark DESTRUCTIVE** any step that deletes a PVC, Secret, or CRD, and require a backup check first.

Output format: a table (resource | policy | reason), then annotated YAML, then the runbook. Do NOT run `helm uninstall` — give me commands to review and run myself.

---

Rendered manifests:
```
[PASTE helm template OUTPUT]
```
Stateful resources: [DESCRIBE]
Release type: [SHARED | DEDICATED]