fix(linux): stop offering a file picker that cannot open

[ayozetr]

On Linux the file picker never opens once the binary carries CAP_NET_RAW, which scripts/run-linux.sh grants by default.

rfd routes dialogs through xdg-desktop-portal, which identifies its caller by opening /proc/<pid>/root. The kernel gates that behind ptrace_may_access, which refuses unless the reader holds a superset of the target's permitted capabilities. The portal holds none, so:

Portal operation not allowed: Unable to open /proc/<pid>/root

pick_file() then returns None, indistinguishable from the user cancelling, so both "choose game" buttons appear to do nothing at all, and nothing surfaces where a user would see it.

Measured rather than inferred — same user, same machine:

process	CapPrm	/proc/<pid>/root
ordinary app	empty	accessible
arctracker-sync after setcap	cap_net_raw	denied

Nothing can satisfy both sides: capture needs the capability for as long as the app can reopen a socket, and a permitted capability can only be dropped, never regained. Restoring the dumpable flag with prctl(PR_SET_DUMPABLE) is not enough either — it fixes the ownership of /proc/self but not the capability comparison, which I confirmed before discarding that approach.

So this detects the situation and offers what does work: Settings swaps the browse button for a text field, and the hub button records why it cannot open a dialog instead of failing silently.

Happy to take this in a different direction if you would rather — switching rfd to its GTK3 backend would restore a real picker, at the cost of a GTK build dependency on Linux (which would partly undo #11).

Context in #8.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}