Rule out the ~/.Xauthority race before blaming X forwarding

Under ssh -X, a GUI tool launched from a script exited with "Can't open display: localhost:N" even though earlier runs had worked. To test the theory that concurrent ssh sessions were racing on the shared ~/.Xauthority, use a private file instead. Copy only this display's cookie into a mode-600 temp file with xauth extract, reading the shared file and never writing it, then export XAUTHORITY pointing at the temp file. Gate the launch on two checks: the cookie exists, and xdpyinfo succeeds on $DISPLAY. If those checks pass in the same shell and the tool still can't open the display, the auth race is ruled out. Then look at how the tool's own bundled X libraries resolve localhost (::1 vs 127.0.0.1); the next test is DISPLAY=127.0.0.1:N for that tool only. Stop on the first failure rather than looping retries on a shared host.