Resolve native symbols for containerized Python processes using the target process root (via /proc/<pid>/root)

### Is there an existing proposal for this?

- [x] I have searched the existing proposals

### Is your feature request related to a problem?

Yes.

When `pystack remote --native ` attaches to a Python process running inside a container runtime such as
Enroot, Python frames can still be visible, but native C/C++ symbol resolution fail for shared
libraries whose mapped paths only exist inside the container filesystem.

A simplified example:

```console
Python process:
loads libnative_hello.so with ctypes

Inside container:
/tmp/pystack-native-symbols-current/libnative_hello.so => exists

Host running PyStack:
/tmp/pystack-native-symbols-current/libnative_hello.so => does not exist
```

The host can still see the target process mappings:

```console
grep libnative_hello.so /proc//maps

Example mapping:

... /tmp/pystack-native-symbols-current/libnative_hello.so
```

But resolving that path directly from the host fails:

```console
test -r /tmp/pystack-native-symbols-current/libnative_hello.so => not readable from host
```

The same file is reachable through the target process root:

```console
test -r /proc//root/tmp/pystack-native-symbols-current/libnative_hello.so => readable
```

### Describe the solution you'd like

When PyStack resolves native symbols for a live process, if opening a mapped ELF path from `/proc//maps` fails, retry the lookup through the target process root `/proc//root/`.

For example, if `/proc//maps` contains:

```console
/tmp/pystack-native-symbols-current/libnative_hello.so
```

and the host cannot open that path directly, PyStack should try:

```console
/proc//root/tmp/pystack-native-symbols-current/libnative_hello.so
```

This would allow PyStack to resolve native symbols for libraries that are visible to the target process but not directly visible in the host filesystem namespace.

The fallback should only be used when direct path lookup fails, so normal host behavior remains unchanged.

### Alternatives you considered

1. Require users to bind-mount container paths at the same location on the host.

This works in some controlled cases, but not feasible with the large container stack used today.

2. Ask users to run PyStack inside the same container.

This can work for simple cases, but it is not always compatible with attach workflows where the debugger/profiler
runs on the host or from a scheduler/tooling process outside the container