Reviewed. Semantics are correct across all 4 locations — I ran the PR's test plus a CodeDomain (LargeValues) variant locally, and the full db/state suite is green.

A few nits, non-blocking:

1. Missing LargeValues test coverage. The PR only exercises AccountsDomain (DupSort). Worth adding a CodeDomain (LargeValues: true) variant so both initCursorMDBX branches and both advanceInFiles DB_CURSOR branches are actually touched by tests. A copy of the existing test with statecfg.Schema.CodeDomain + tx.Delete(d.ValuesTable, key||^step1) (instead of DeleteExact on the dup) works.

2. initCursorMDBX LargeValues loop is step-by-step instead of userKey-by-userKey. For a userKey with N steps all within the file range, it does N step-extractions via single Next() calls. Not incorrect, since every intermediate step is also within range, but it's redundant. A prefix-scan would avoid the per-step computation:

if endTxNum < hi.filesEndTxNum {
    prev := common.Copy(k)
    for {
        key, value, err = valsCursor.Next()
        if err != nil { return err }
        if len(key) < 8 || !bytes.Equal(key[:len(key)-8], prev) { break }
    }
    continue
}

3. advanceInFiles LargeValues structure. Wrapping Current() + the inner advance loop inside the outer skip-loop works but is harder to follow than separating "advance past the just-popped userKey" (once, up front) from "keep skipping within-range userKeys" (the loop). Each outer iter effectively advances past one userKey. Style only.

4. len(key) >= 8 defense. key != nil is checked but key[:len(key)-8] isn't guarded. Realistically impossible with well-formed data, but len(key) > 8 is cheap insurance in the LargeValues paths.

5. Description overstates the "shadowing fix". value = value[8:] was reassignment, not shadowing, and wasn't a bug — common.Copy(value) copied correctly from the shifted slice. The val := value[8:] change is a clarity win (especially inside the new loop), just not a bugfix.

One broader note

Unlike debugIteratePrefixLatest (where the original bug was endTxNum: math.MaxUint64, making stale DB entries win outright), DomainLatestIterFile already derived endTxNum from the step — so the heap comparator was already picking file entries over stale DB entries at the same key. The tests therefore pass with or without the fix on its own. The fix's real value is consistency with the #16239 family and fewer heap pushes / DB reads, not a user-visible bug — worth keeping in mind when phrasing the PR as a correctness fix.

LGTM overall.

Thanks for the thorough review!

Addressed in fc77573:

1. LargeValues test coverage — added TestDomainLatestIterFile_PrefersFilesOverDB_LargeValues using CodeDomain to exercise both initCursorMDBX and advanceInFiles LargeValues branches.
2. len(key) > 8 defense — added guards at 3 locations in the LargeValues paths (initCursorMDBX loop condition, advanceInFiles inner loop, and changed len(k) == 0 → len(k) <= 8 in the break condition).
3. Cursor leaks — added pushed bool pattern to both initCursorMDBX paths (LargeValues + DupSort) to close valsCursor when nothing is pushed to the heap.
4. defer iter.Close() in test.
5. PR description — reworded "shadowing fix" → "clarity improvement" and added a note that the primary value is consistency with db property: if data in files, don't read it from db #16239 + fewer heap pushes, not a user-visible correctness fix.

Skipped nits 2 (prefix-scan efficiency) and 3 (advanceInFiles structure) — both non-blocking, and the refactoring risk outweighs the marginal benefit in these paths.

please cp to release when merged