Obsolete versioned config-maps are not deleted on first apply

**What steps did you take:**

- Create a versioned configmap
- Update the config map 5 times to create 6 configurations

**What happened:**

Running a new apply with **no changes** triggers the deletion of the first configmap that should have been deleted in the previous run making a very confusing diff. This makes CI/CD diff reviews quite hard to read.

**What did you expect:**

For the obsolete versions to be deleted on the apply run it becomes obsolete (after everything else has been applied successfully)

**Anything else you would like to add:**

Posted on slack about it a few months ago and did not get many answers : https://kubernetes.slack.com/archives/CH8KCCKA5/p1760004111926489

**Environment:**

- kapp version (use `kapp --version`): v0.65.1
- OS (e.g. from `/etc/os-release`): Any OS (Ubuntu / MacOS...)
- Kubernetes version (use `kubectl version`) : v1.33.5

---
Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

Start by reproducing the issue with a versioned ConfigMap, updating it five times, and applying with no changes. Trace the apply and obsolete-version deletion handling in the kapp codebase; done means obsolete versions are deleted during the run in which they become obsolete, after successful application, without a confusing deletion on the next no-op apply.

Written by the indexing model from the issue text.