fleet check: catch the two config faults that have each cost a whole fleet

[devdanzin]

Both faults were found by triaging fleets that had already burned their time on them, and
both are one line of config to fix once you know which line.

1. The target must be executable by the fuzz user

fleet check already did [ -x "$TARGET_PYTHON" ] — but that asks whether you can execute
it. fusil drops privileges before exec'ing the target, so a build under someone's home
directory is routinely executable by its owner and unreachable for the fuzz user, whose
traversal fails on a path component:

ChildError: The user fusil is not allowed to execute the file /home/danzin/.local/bin/pypy3.11

That surfaces once per session, kills the run, and the supervisor restarts into the same wall.
Two fleets opened that way on two different paths — one lost 36 of 65 runs, the other 6.

Checked by walking the mode bits of every path component, not by sudo-ing to the user:
same answer, needs no privilege (passwordless sudo is absent on exactly the boxes where this
bites), and it names the component that actually blocks.

  TARGET_PYTHON is not reachable by user 'fusil': '/tmp/x/inner/python'
    blocked at: /tmp/x/inner
    -> chmod o+X /tmp/x/inner

Both the literal path and its realpath are walked. Checking only the resolved one is a
hole: to exec a symlinked target the kernel must traverse the link's own directories before it
resolves the link, and build trees commonly symlink the interpreter. My first version had that
hole and passed a deliberately-blocked symlinked target.

Skipped under --unsafe / --force-unsafe, where no drop happens.

2. Discovery must run in an interpreter that has the modules

Without --discover-in-target, fusil imports the target's modules in the runner, so a
runner that is not the target yields a module list and member set the target does not have. A
PyPy fleet ran 43 368 sessions that way against a CPython 3.16 runner: 20% of the modules
it picked do not exist on PyPy at all, and the importable remainder still exposed members it
lacks.

Calibrated deliberately, and this part matters:

different implementation	fails — cpython-vs-pypy stdlibs diverge by construction; discovery in the wrong one is never right
different version, same implementation	advisory — costs coverage at the edges, does not systematically break

Without that split this would have blocked fleet_multidict.conf, which works and has produced
findings (CPython 3.14 runner, 3.16 target, --modules=multidict so stdlib discovery is not
even in play).

Verified against every fleet*.conf on this host

config	before	after
fleet_rustpython.conf	passed	fails — CPython runner, RustPython target, no flag. A real instance of fault 2.
fleet_multidict.conf	passed	passes, with an advisory
all others	passed	passes

Regression matrix for the new logic:

case	result
runner == target, --unsafe	PASS
PyPy target, no --discover-in-target	FAIL
PyPy target, with --discover-in-target	PASS
symlinked target behind a 0700 dir	FAIL
… after chmod o+X	PASS
… blocked again but with --unsafe	PASS

1293 tests OK, ruff check and ruff format --check clean. (The change is in fleet/fleet,
which the Python suite does not cover; the matrix above is the verification.)