Misleading "Steam now requires user namespaces" error when bwrap fails on a stale systemd automount mount

Environment

• Arch Linux rolling, kernel 7.1.8-arch1-3
• steam 1.0.0.87-1 (native package)
• KDE Plasma 6.7, Wayland
• GPU: AMD RX 7900 XT (amdgpu)

Symptom

Launching Steam fails immediately with:

Error: Steam now requires user namespaces to be enabled.
This requirement is the same as for Flatpak...

However, user namespaces are enabled and working on this system:

• /proc/sys/user/max_user_namespaces = 62287
• unshare -Ur succeeds as a regular user

Actual root cause

steam-runtime-check-requirements fails because bwrap cannot replicate
a stale systemd automount mount point:
steam-runtime-check-requirements[3859]: W: Child process killed by signal 15: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/mnt/win-c": No such device

Context: this is a moving SSD installation. /etc/fstab contains an
x-systemd.automount entry for an NTFS partition that exists on another
machine but not on this one. systemd still creates the autofs mount point;
when the backing device is absent the mount is dead, and bwrap aborts while
building its mount table — which the requirements check then misreports as
"user namespaces not enabled".

Removing the automount entry (or cleaning up the stale mount point) makes
Steam start normally, with no other changes.

Suggestion

When bwrap fails for reasons other than a genuine userns problem,
steam-runtime-check-requirements should surface the underlying bwrap
error instead of concluding that user namespaces are disabled. A hint like
"check for stale/FUSE/network mount points in your mount table" would have
saved hours of debugging.

Start at the steam-runtime-check-requirements entry point and reproduce the failure with bwrap against the stale systemd automount described in the issue. Trace how the bwrap failure becomes the user-namespace error. Done means genuine user-namespace failures still report correctly while other bwrap errors, including the underlying mount error, are surfaced with a useful mount-related hint.