Certain relative-path dynamic linking causes failure

@jaybosamiya-ms is already working on this.

Since Nov 7, 2025.

I have partly debugged this (the "obvious" fixes at the testing level just surface more issues with the relative-path dynamic linking), so more debugging is needed, and thus I am opening this as a tracking issue.

Python 3.10.12 (as pulled from the [redistributable precompiled builds](https://github.com/astral-sh/python-build-standalone), which I personally use via [mise](https://mise.jdx.dev/)) fails. This is distinct from the failure in #477 (rewriting succeeds), but then some path shenanigans cause execution to fail. Effectively, it fails with a `undefined symbol: Py_BytesMain`.

If we start chasing down the rabbit hole (useful help: `--env LD_DEBUG=libs`), we see
```
cannot load auxiliary `$ORIGIN/../lib/libpython3.10.so.1.0' because of empty dynamic string token substitution
```

Moving things into the "right place" (because by default, the test uses a moved location) is insufficient.

To figure out if a particular `python3` will fail this way, it is enough to do
```console
$ strings $(which python3) | grep '$ORIGIN'
$ORIGIN/../lib/libpython3.10.so.1.0
```

The versions of Python on many people's systems when they run `which python3` (and also on the CI) will probably not hit this issue, but nonetheless for anyone who gets a `$ORIGIN` in their python3, there will be failures that we should fix.

---

To trigger things:
```console
$ cat .tool-versions
python 3.10.12

$ cargo nextest run --nocapture python
......
Running `..../litebox_runner_linux_userland --unstable ..../python3.hooked -c print("Hello, World from litebox!")`
......

$ ..../litebox_runner_linux_userland --unstable ..../python3.hooked -c 'print("Hello, World from litebox!")'
........
undefined symbol: Py_BytesMain
```