TL;DR:

Stock KDE interaction with stock pipewire, demands a greater number of
open file descriptors, than stock systemd permits.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4047
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4378

Also affects firefox

https://bugzilla.mozilla.org/show_bug.cgi?id=1974718

Wim Taymans in #4047 has linked to a commit that just landed that
might fix the issue (short lived streams trigger it - which would very
much describe firefox which wants to open a new stream for every tiny
little sound effect):

 cfde4c1b for issue #4901 (closed)

Please backport that commit to stable (oldstable would be nice too,
but probably out of the question).

I ran into this bug with 1.4.2-1 after upgrading to trixie. I believe
that including https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2544
(commit cfde4c1b17468d82c34555814dc19998d00d7bd1) will fix it. It
looks like it cherry-picks cleanly, although I did not try building
yet.

I think https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/4901
is the correct upstream bug, because it's the only upstream bug I
found which mentions an indefinite increase in FDs. I found that the
bug triggered consistently when leaving pavucontrol open while using
Chrome and Firefox, and closing pavucontrol immediately freed most of
the FDs opened by pipewire-pulse. I also found that increasing the
RLIMIT_NOFILE soft limit for pipewire-pulse extended the time until
running out of FDs, although the number of FDs kept increasing
seemingly indefinitely (I got up to 2445 at one point).

Another interesting observation for identifying this bug is that the
timestamps of most of the excessive FDs in `/proc/$(pidof
pipewire-pulse)/fd` show they are opened in big batches which
correspond to me switching between desktops which have web browser(s)
and a pavucontrol window open.

The symptoms with current Firefox and Chrome (installed from upstream
apt sources) are that video/audio streams freeze for some time (up to
a minute or so) before starting or unpausing, and then some of them
work normally while others render very slowly (a handful of frames per
second). Looping video streams play the same way (normally or at a few
frames per second) when they loop, with no delay. Sometimes the entire
tab freezes while the video/audio is frozen, other times it's just the
video/audio and the rest of the tab works, with no apparent pattern.

Some Debian bugs that might be duplicates, although it's hard to tell
from the provided information:
#1056383
#1012563