Using `dnf` inside of a toolbox can result in failed systemd units outside.

**Describe the bug**

I initially observed this behavior using `dnf` to install a package inside of a `fedora-toolbox-41` toolbox, after which I was warned about failed transient systemd units _outside_ of the toolbox, which seemed strange. After a bit of digging, I tracked the specific failed unit, shown in the example below, down to a [trigger](https://src.fedoraproject.org/rpms/man-db/blob/f41/f/man-db.spec#_159-169) provided by the `man-db` package to update its cache:

```
%transfiletriggerin -- %{_mandir}
# update cache
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update >/dev/null 2>&1 || :
fi
```

Although this trigger makes an effort to ensure that it's only run when the required tools are available, because `/run/dbus/system_bus_socket` is bind mounted at the same path inside of the toolbox the trigger believes that it is being run in an environment that is managed by systemd. In my case, although `man-db` in installed inside of the toolbox, it is not installed outside, and so `man-db-cache-update` is not present there and thus the transient service unit created by `systemd-run` fails. It is not this failure that is the surprising part, however, but rather the more general effect that `dnf` inside of the toolbox had on the environment outside.

**Steps how to reproduce the behaviour**

1. Ensure that there are initially no failed units.
```
root@localhost:~# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
```

2. Create a new toolbox, using the default in this example.
```
root@localhost:~# toolbox create
Created container: fedora-toolbox-41
Enter with: toolbox enter
root@localhost:~# toolbox enter

Welcome to the Toolbx; a container where you can install and run
all your tools.

- Use DNF in the usual manner to install command line tools.
- To create a new tools container, run 'toolbox create'.

For more information, see the documentation.
```

3. Use `dnf` to install any package. (The `iw` package here is arbitrary.)
```
⬢ [root@toolbx ~]# dnf install -y iw

Complete!
⬢ [root@toolbx ~]# exit
logout
```

4. Observe the new failed transient service unit outside of the toolbox.
```
root@localhost:~# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● run-u233.service loaded failed failed /usr/bin/systemctl start man-db-cache-update

Legend: LOAD → Reflects whether the unit definition was properly loaded.
ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
SUB → The low-level unit activation state, values depend on unit type.

1 loaded units listed.
```

**Expected behaviour**
I would not expect installing a package - or taking other similar "local-feeling" toolbox actions - inside of a toolbox to create or manipulate systemd units outside of the toolbox. The fact the unit in this particular example failed is what called my attention to it, but even without the failures this behavior is still unexpected. `systemctl`, for example, refuses to run inside of the toolbox unless `SYSTEMD_IGNORE_CHROOT=1` has been explicitly set to opt-in to this behavior.

**Actual behaviour**
Processes inside of the toolbox, including side-effects as in this `dnf` example, can effect changes outside of the toolbox via interaction with `systemd` running outside.

**Screenshots**
N/A

**Output of `toolbox --version` (v0.0.90+)**

```
root@localhost:~# toolbox --version
toolbox version 0.1.1
```

**Toolbx package info (`rpm -q toolbox`)**

```
root@localhost:~# rpm -q toolbox
toolbox-0.1.1-1.fc41.x86_64
```

**Output of `podman version`**

```
root@localhost:~# podman version
Client: Podman Engine
Version: 5.3.1
API Version: 5.3.1
Go Version: go1.23.3
Built: Thu Nov 21 00:00:00 2024
OS/Arch: linux/amd64
```

**Podman package info (`rpm -q podman`)**

```
root@localhost:~# rpm -q podman
podman-5.3.1-1.fc41.x86_64
```

**Info about your OS**

```
root@localhost:~# cat /etc/os-release
NAME="Fedora Linux"
VERSION="41.20241215.3.0 (CoreOS)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=41
VERSION_CODENAME=""
PLATFORM_ID="platform:f41"
PRETTY_NAME="Fedora CoreOS 41.20241215.3.0"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:41"
HOME_URL="https://getfedora.org/coreos/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/"
SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=41
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=41
SUPPORT_END=2025-12-15
VARIANT="CoreOS"
VARIANT_ID=coreos
OSTREE_VERSION='41.20241215.3.0'
```

**Additional context**
N/A