JuliaCall 0.9.35 regression: initialization fails when Julia executable is a symlink

**Affects:** JuliaCall

### Describe the bug

JuliaCall 0.9.35 fails during initialization when Julia is discovered through a symlink outside its installation directory. It searches for `sys.so` relative to the symlink's directory rather than Julia's actual binary directory.

The same setup works with JuliaCall 0.9.34. Version 0.9.35 also works when the real executable directory is used instead. The failure can be reproduced with a standalone `import juliacall`.

### Reproduction

Prerequisites: `uv` and an existing Julia 1.12.7 installation. Set `JULIA_REAL` to its actual executable, not a symlink or Juliaup launcher. Run without JuliaCall/JuliaPkg configuration overrides or `juliaup` on the probe's `PATH`.

```bash
JULIA_REAL=/absolute/path/to/julia-1.12.7/bin/julia

work="$(mktemp -d)"
mkdir -p "$work/link/bin"
ln -s "$JULIA_REAL" "$work/link/bin/julia"

uv venv --python 3.14.5 "$work/venv"
uv pip install --python "$work/venv/bin/python" \
juliacall==0.9.35 juliapkg==0.1.26

PATH="$work/link/bin:/usr/bin:/bin" \
JULIA_DEPOT_PATH="$work/depot" \
"$work/venv/bin/python" -I - <<'PY'
import juliapkg

print("Selected executable:", juliapkg.executable(), flush=True)

import juliacall
PY
```

JuliaPkg selects `/link/bin/julia`. Julia package setup succeeds, but embedded initialization exits with:

```text
ERROR: could not load library "/link/bin/../lib/julia/sys.so"
/link/bin/../lib/julia/sys.so: cannot open shared object file: No such file or directory
```

**Expected:** importing JuliaCall should work through the symlink, as it does through the real executable path.

### Controlled comparison

Each case used a separate Python environment and Julia project, with the same Python, Julia, and JuliaPkg versions:

| JuliaCall | Discovered executable | Result |
|---|---|---|
| 0.9.35 | Symlink | Initialization fails; exit 1 |
| 0.9.35 | Real path | Imports successfully; evaluates `1 + 1` to `2` |
| 0.9.34 | Symlink | Imports successfully; evaluates `1 + 1` to `2` |

### Your system

- Standalone reproduction: Arch Linux, x86_64
- Original failure: GitHub Actions `ubuntu-24.04`, where `/usr/bin/julia` points to `/usr/local/julia1.12.7/bin/julia`
- Python: 3.14.5 in the standalone reproduction
- Julia: 1.12.7

Installed Python packages in the failing environment:

```text
filelock 3.32.6
juliacall 0.9.35
juliapkg 0.1.26
semver 3.0.4
tomli 2.4.1
tomlkit 0.15.1
```

`juliapkg.status()` output, with temporary paths shortened:

```text
JuliaPkg Status
/venv/julia_env/pyjuliapkg/juliapkg.json (empty project)
Julia 1.12.7 @ /link/bin/julia
```

### Additional context

This appears to reintroduce the failure described in [#196](https://github.com/JuliaPy/PythonCall.jl/issues/196), which was fixed in 2022.

[PR #782](https://github.com/JuliaPy/PythonCall.jl/pull/782), included in 0.9.35, supplies `libpath` through `juliapkg.libjulia()`. This skips the subprocess that also discovers `Sys.BINDIR`. With no explicit `bindir`, initialization then falls back to:

```python
bindir = os.path.dirname(exepath)
```

For a symlink such as `/usr/bin/julia`, that produces the wrong directory. Restoring discovery of Julia's actual `Sys.BINDIR`, or otherwise handling the symlink correctly, should address this initialization failure.

Start by tracing JuliaCall initialization around juliapkg.libjulia(), the missing bindir, and the fallback that derives bindir from exepath. Reproduce the issue with the supplied uv environment and symlink setup, then verify that importing juliacall succeeds through the symlink as it does with the real executable path.

Written by the indexing model from the issue text.