erofs: share one inode per hardlink, and fix the stale mode-bit comments

[smoser]

Two loose ends from #2408 that both come out of the go-erofs bump in #2412,
neither of which belongs in the layer-splitting PR (#2418). Independent of
that one and of #2415.

1. The mode-bit comments are stale

pkg/build/erofs.go described the Chmod after Mkdir/Mknod/Create as a
workaround for the pinned go-erofs, to revisit "once a release containing
[erofs/go-erofs#41] is out". #2412 bumped the pin past that merge, so both
halves of the claim are now wrong. Probing the pinned version:

	claim in the comment	actual
Mkdir with setuid/setgid/sticky	drops them	keeps them
FileInfo.Mode() on read	cannot be trusted for those bits	reports them

The Chmod still has to stay, for a reason that has nothing to do with #41
and is not going away: Writer.Create takes no mode argument at all, so every
regular file starts life 0644. Mkdir and Mknod do take one, but apko
hands them mode.Perm() and lets the single Chmod cover all three rather
than splitting the rule across three call sites. So this is a comment change,
not a code change.

pkg/erofsmount/ls.go keeps reading *erofs.Stat off Sys() — fs.FileInfo
has nowhere to put a uid or a device number — but its comment justified that
with the setuid claim, which no longer holds.

TestWriteErofs_SpecialModeBits now also asserts FileInfo.Mode() == Stat.Mode for every case it covers (setuid and setgid regular files, a sticky
directory, a char device, a symlink), which pins the half that changed.

2. Hardlinks point at one inode

go-erofs grew Writer.Link(oldname, newname), which gives a second name the
same fsInode as the first and maintains nlink. apko was still materializing
every hardlink as an independent copy, because when #2249 landed there was no
API for it — SetNlink sets the reported count without sharing the inode, so
it would only have made the metadata lie.

A hardlink reaches the writer as an ordinary second dirent; its linkness lives
only in the *tar.Header from Sys(), which pkg/tarfs fills in from the apk
it unpacked. hardlinkTarget reads it from there — the same place the tar
layer path finds it via tar.FileInfoHeader. A rootfs read back off disk
(apkfs.MemFS, rwosfs) records nothing, so those keep getting a copy per
name, exactly as before.

Two details worth review:

• Links are held back until the walk finishes. Writer.Link needs the
  target to already exist and fs.WalkDir is lexicographic, so /usr/bin/[
  arrives long before /usr/bin/coreutils.
• A link whose target is missing from the image falls back to a copy. That
  is the cross-layer case: §3.7 requires a hardlink spanning layers to be
  materialized or the build to fail, and apko materializes. It cannot happen in
  a single-layer image, but layer splitting (erofs: restore multi-layer splitting, with the bugs review found fixed #2418) is what puts a link and its
  target in different writers, so the fallback is there and tested now rather
  than after that lands.

Nothing is re-applied to a shared inode — mode, ownership, timestamps and
xattrs came with it.

Verification

gofmt -l clean, golangci-lint run -n reports 0 issues, go build ./... and
GOOS=darwin go build ./... both succeed, SOURCE_DATE_EPOCH=0 go test ./...
passes.

The behavioural tests were checked to fail without the change, by making
hardlinkTarget always return false and re-running:

Error: Not equal:            Messages: link count
Error: "196608" is not less than "32768"
       three hardlinks grew the image by 196608 bytes, which looks like copied data

196608 is exactly three more copies of the 64K fixture file. With the change
the three names share one inode, report nlink 3, and fsck.erofs accepts the
image.

Refs #2408

🤖 Generated with Claude Code