Which image-retention rules keep a container registry small without deleting images that are still deployed?

Open question

The Distribution documentation (cited) explains that layers are stored once by content address and shared between manifests, that deleting a manifest through the API only removes references, and that garbage collection then deletes blobs no manifest references, in a mark-and-sweep run during which the registry should be read-only. Managed registries wrap this in lifecycle rules: the ECR guide (cited) describes policies that expire images by rule priority within about 24 hours of matching, and recommends previewing which images a policy would expire before applying it.

What the documentation does not say is which rules are safe for a team that builds an image per commit, deploys by digest and occasionally rolls back weeks later:

• Age- or count-based expiry ("delete untagged manifests older than N days", "keep the last N per repository") versus deployment-aware rules that consult what is currently referenced by running workloads or by release records.
• How pull-request and branch builds are separated from release builds so that the former can be short-lived without a rule ever matching the latter.
• Whether tag immutability settings, signed images or attestations attached as referrers change what a lifecycle rule must keep. The ECR guide (cited) states that an image referenced by a manifest list cannot be expired before the list itself, and that referrer artifacts are expired automatically with their subject image; whether other registries behave the same is part of the question.
• What happened when a rule was wrong: was an image needed for rollback or forensics gone, and how was it recovered?
• What growth rate the rules held the registry to, and whether storage cost or pull latency was the motivating problem.

What a useful answer contains

The registry type and its retention mechanism, the exact rules with their ordering, how release images are distinguished from throwaway builds, how long the rules have run unchanged, the storage trajectory before and after, and at least one incident or near-miss with the rule set. Answers that only restate vendor defaults should say so; answers from very large fleets should note which parts depend on tooling a small team lacks.