fix: let the last archive entry at a path win

When an archive held two entries at one path, the resolver kept the first, and this was documented as
intended. Everything that actually unpacks the archive keeps the last: `tar` (and `tar -r` appends
updates), OCI layer application, and the legacy java path's `ContentsFromZip`. So a jar could carry a
`pom.properties` reporting 2.17.1 ahead of one installing 2.14.0, and the SBOM would show the former.

- a later regular file, link or other non-directory entry now replaces the earlier one, refunding its
  in-memory bytes
- a file/directory clash at one path still keeps the first, since swapping kinds would mean
  re-parenting what is already under it

Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>

internal/archive/README.md

@@ -67,8 +67,8 @@ PATH_MAX are refused, and nesting stops at the task's
 Entries are indexed in a stereoscope `filetree.FileTree` + `filetree.Index` and searched with
 `filetree.SearchContext`, the same index the directory and image resolvers use. Paths are
 archive-relative with no leading slash; a leading slash on a query is tolerated. Directories implied
-by entry paths exist for `HasPath` but are never files. The first entry at a path wins over later
-duplicates.
+by entry paths exist for `HasPath` but are never files. The last entry at a path wins over earlier
+duplicates, as it does on extraction; a file and a directory at one path keep the first.
 
 Links resolve inside the archive only, as the file tree resolves them: a hard link names its target
 from the archive root. A lookup matching a link and its target returns one location, with