[Upstream regression / visibility] crun >= 1.29 can break host PTYs when starting a rootful Distrobox

Please, before opening a bug:

- [x] I have read the documentation.
- [x] I searched existing open issues.
- [x] I searched existing closed/resolved issues.

**Describe the bug**

This report is a cross-reference for visibility only. The underlying regression
is being tracked by crun:

https://github.com/containers/crun/issues/2197

Starting a rootful Distrobox container through Podman with crun 1.29 or newer
can result in the container's anonymous `/dev/pts` volume appearing over the
host's real `/dev/pts` mount.

Once this happens, `/dev/pts/ptmx` is no longer visible on the host and new
pseudoterminals cannot be allocated. This affects `sudo`, terminal emulators
and other applications that require PTYs.

The upstream report confirms:

- crun 1.28 works.
- crun 1.29 is affected.
- crun 1.29.1 is affected.
- current crun main is affected.

I reproduced this with Distrobox v1.8.2.5. I have not runtime-tested Distrobox
v2 because reproducing the issue disrupts PTY allocation across the host and
requires recovery.

**To Reproduce**

Warning: It can prevent new terminals and `sudo` sessions from working on the host.

1. Use Podman with crun 1.29 or 1.29.1.

2. Create a rootful, initful Distrobox:

```bash
distrobox create \
--root \
--name crun-devpts-repro \
--image docker.io/library/debian:stable \
--init
```

3. Confirm the host initially has a normal devpts mount:

```bash
findmnt -rn -o TARGET,SOURCE,FSTYPE /dev/pts
```

Expected initial output:

```text
/dev/pts devpts devpts
```

4. Start or enter the rootful container:

```bash
distrobox enter --root crun-devpts-repro
```

Starting it directly through Podman can produce the same result:

```bash
sudo podman start crun-devpts-repro
```

5. Inspect the host:

```bash
findmnt -rn -o TARGET,SOURCE,FSTYPE /dev/pts
stat -f -c '%T' /dev/pts
ls -l /dev/pts/ptmx
python3 -c 'import os,pty; a,b=pty.openpty(); print(os.ttyname(b))'
```

6. The anonymous Podman volume appears over the host `/dev/pts`. The
filesystem reports `btrfs` rather than `devpts`, `/dev/pts/ptmx` is
missing, and `openpty()` fails.

**Expected behavior**

The container's `/dev/pts` mount should remain isolated from the host mount
namespace.

**Logs**

Distrobox/entry failure:

```text
sudo: unable to allocate pty: No such device
Error: could not start entrypoint.
sudo: unable to allocate pty: No such device
```

Host mount state after starting the container:

```text
/dev/pts devpts devpts
/dev/pts /dev/sdd1[/@containers/storage/volumes//_data] btrfs
```

Host PTY checks:

```text
$ stat -f -c '%T' /dev/pts
btrfs

$ ls -l /dev/pts/ptmx
ls: cannot access '/dev/pts/ptmx': No such file or directory

$ python3 -c 'import os,pty; a,b=pty.openpty(); print(os.ttyname(b))'
OSError: out of pty devices
```

The kernel was not actually out of PTYs:

```text
$ paste -d/ /proc/sys/kernel/pty/nr /proc/sys/kernel/pty/max
4/4096
```

**Desktop (please complete the following information):**

- Container manager: Podman
- Podman version: 6.1.0-1
- OCI runtime: crun 1.29.1-1
- Distrobox version tested: 1.8.2.5-1
- Distrobox v2: source inspected, not runtime-tested
- Host distribution: Arch Linux
- Kernel: 6.18.44-1-lts
- Installation method: Arch Linux packages via pacman
- Container type: rootful and initful

**Additional context**

The affected container was created before the crun 1.29 update and did not
previously cause this host-wide failure.

The upstream crun report contains version comparisons and tracks the underlying
regression:

https://github.com/containers/crun/issues/2197

This Distrobox issue is intended only as a visibility and cross-reference item.
No Distrobox-side change or workaround is being requested.

This report was created by AI and cross checked by me, apologize if there is any issue with the wording, thanks!