erofs: add a privileged CI job that mounts a layer

[smoser]

First of the section 1 items from #2408, and the one that makes the rest of
them testable.

Why

Every EROFS check that exists today runs unprivileged and reads the image back
with go-erofs — the same library that wrote it. That arrangement cannot see a
misunderstanding shared by our writer and our reader. fsck.erofs appears in
pkg/build/erofs_test.go as an optional second opinion, but nothing anywhere
has ever handed an apko-produced EROFS layer to the kernel driver.

The pre-descope tree in #2249 didn't either — grepping .github/ on
feat/apko-erofs-full for "erofs" returns nothing. So this is new work rather
than a restore.

What it does

hack/test-erofs.sh follows the recipe docs/erofs.md already publishes:
build into an OCI layout with --format=erofs, resolve the layer blob through
index.json and the manifest, then

1. assert the layer mediaType is application/vnd.erofs, and that the blob's
   filename matches sha256 of its own bytes — the layer is stored
   uncompressed, so digest == diffID, and a compression step creeping into
   this path fails here;
2. fsck.erofs -d3 and dump.erofs — the C implementation's opinion;
3. mount -t erofs -o ro — the kernel's opinion;
4. compare apko erofs ls against the mounted tree: path, mode string,
   uid/gid and symlink target, for every entry.

Step 4 is the point of the job. On examples/wolfi-base it covers 395
entries, including a sticky directory (tmp), five char devices with rdev,
237 symlinks and several non-root uid/gid pairs. setuid and setgid aren't
present in that fixture; the writer's handling of those stays covered by the
optional fsck.erofs checks in pkg/build/erofs_test.go.

The comparison is verified to have teeth: fed a listing with the sticky bit
rewritten to drwxrwxrwx, the job fails with

-drwxrwxrwt 0/0 tmp
+drwxrwxrwx 0/0 tmp
'apko erofs ls' disagrees with the kernel about the layer contents

That is the class of bug the go-erofs bump in #2412 was about — Mkdir
dropping setuid/setgid/sticky on write and FileInfo.Mode() misreporting them
on read.

Job details

erofs is a module rather than built in, and the runner image doesn't ship
every module, so the workflow tries modprobe first and only downloads
linux-modules-extra-$(uname -r) if the module is genuinely absent. It fails
in that step rather than inside the script, where an absent driver would read
as a mount bug. There is no silent skip — an unavailable driver is a red job,
not a quiet pass.

The script installs nothing itself, so it stays usable locally. Package
installation lives in the workflow.

sudo on ubuntu-latest is already established practice here:
go-tests.yaml installs erofs-utils the same way.

Verification

Ran end-to-end in a privileged ubuntu:24.04 container against a real kernel
mount, not just dry-read: fsck.erofs reports "No errors found", 395 entries
agree, umount is clean. Plus the negative test above.

shellcheck -e SC2129 clean (matching the actionlint config), actionlint
clean, zizmor --persona pedantic --config .github/zizmor.yml reports no
findings.

Not in this PR

The rest of section 1 of #2408: restoring apko erofs mount/umount with
state-file containment, partial-unmount recovery, a read-only default and a
Driver test seam. That work is deliberately second — this job only exercises
what is already on main, so it can land green now, and once it is here the
restored mount has somewhere to be tested. It will extend this job rather
than add another.

Refs #2408

🤖 Generated with Claude Code

[smoser]

Note for reviewers on the apko erofs ls ↔ kernel comparison: splitting the
listing with awk '{print $1, $2, $6}' is why the script has to reject paths
containing whitespace up front. That's interim.

The plan is a follow-up PR moving that comparison into a privileged Go test,
which buys two things the shell version can't have:

• a structured comparison (filepath.WalkDir + Lstat against the reader)
  instead of column arithmetic on formatted output, with per-entry diffs;
• a purpose-built fixture. Coverage of special bits here is accidental —
  wolfi-base happens to give us a sticky /tmp and five char devices, and
  no setuid or setgid at all. A Go fixture can place setuid, setgid, sticky,
  hardlinks and devices deliberately and assert the kernel agrees on each,
  which is exactly the class of bug behind Fix setuid/setgid/sticky bits dropped on read and in Mkdir erofs/go-erofs#41 and the bump in
  Bump go-erofs import to current main. #2412.

This job keeps the part that is genuinely shell-shaped either way: the CLI
contract of apko build --format erofs out/ producing a mountable OCI layout,
following the recipe docs/erofs.md publishes. internal/cli has no tests
that drive cobra in-process, so a library-level Go test would not cover the
output dir-vs-tar branch at internal/cli/build.go:163.

Gating a root-only Go test is new machinery for this repo — nothing here is
root-gated today — so it wants go test -c plus sudo rather than
sudo go test, and the walk needs root too, not just the mount.