Why we don't drop changes in pendingDVUpdates here?

https://github.com/apache/lucene/blob/84cae4f27cfd3feb3bb42d5a9f7ce034f7a31573/lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java#L264

```
public synchronized void dropChanges() {
// Discard (don't save) changes when we are dropping
// the reader; this is used only on the sub-readers
// after a successful merge. If deletes had
// accumulated on those sub-readers while the merge
// is running, by now we have carried forward those
// deletes onto the newly merged segment, so we can
// discard them on the sub-readers:
pendingDeletes.dropChanges();
dropMergingUpdates();
}
```

For the code above, why we don't drop changes in pendingDVUpdates ? Otherwise, for merged away segment, DV updates could still be written into disk here https://github.com/apache/lucene/blob/84cae4f27cfd3feb3bb42d5a9f7ce034f7a31573/lucene/core/src/java/org/apache/lucene/index/ReaderPool.java#L184

Start with ReadersAndUpdates.java at dropChanges() and follow the pendingDVUpdates handling into ReaderPool.java around line 184. Trace how merged-away segments and document-value updates are processed, then determine whether the observed disk write is expected or requires a change. Done means the behavior is explained and, if necessary, covered by an appropriate Lucene test.

Written by the indexing model from the issue text.