Fix docs about "listed" behavior

[LukasKalbertodt]

Text copied from the second commit:

---

Our docs described a behavior that was implemented differently. This
commit fixes this inconsistency. We discussed this in detail internally
and believe the suggested behavior (which already happened to be
implemented) is the most useful one for Tobira. An explanation of the
three most discuss-worthy points:

(1) Series do NOT become listed via a video-block of their videos:

It is fine that only the event is findable, especially since "series
title" is part of the event data in the search index, so you can find
that event via the series title. And then the series is only one click
away. So why not make the series findable directly as well? It's not
necessary for UX, and would be a lot more complicated
implementation-wise.

(2) Events do NOT become listed via video-blocks of other videos in
their series:

For one, that might be unexpected to some users, especially because
spooky action at a distance. But it also leads to user confusion
elsewhere: if it were findable, then the "manage my events" page for
that event should better also list the page responsible for that
under "referencing pages", but then users might only see another event
on that page, being confused. However, even if these events are not
findable via search, they are "reachable", namely by finding another
video in the series, and then clicking a couple of times. For that
reason we adjusted the phrasing of our "unlisted" note (which is still
hidden behind the experimental feature flag, so no user ever saw it
yet). The new phrasing promises a bit less.

(3) Events DO become listed via playlist-blocks of a playlist containing
them:

At first this seems like a bad idea as every user can add every event to
all playlists they have write access to (for example: their own). So
can every user make any event listed then? No: the playlist block still
needs to be added to a non-user page, which requires a privilege that
likely only few trusted users have. And if they have that privilege,
they can just as easily add a video block with that video directly, so
no one gets any additional powers for mischief. But wait: what if
someone has write access to a playlist that is already mounted on a
non-user page and they add a video there? Yes that is the other option
on how to make the video listed, however: they also need access to such
a playlist first. And note: even if we don't make the event findable
via a playlist block: the event could still be reached by clicking
around in the non-user pages! So it is already not hidden anymore. And
finally: to add a video to a playlist, that person needs to have the
ID (or a link) to that video in the first place. If they had malicious
intends of making the video public, they might as well just e-mail the
link around or something like that.

So in summary: while it first sounds a bit dangerous, thinking it
through shows that there are basically no way in which we give untrusted
users more power to do unintended things.

On the other hand, there are a few advantages of making events findable
via playlist block. To users, a playlist block looks basically like a
series block: the video with its thumbnail "is clearly on this page".
Having different behavior for both could be confusing. Further, we would
like to allow "video in context" pages, i.e. /path/to/realm/v/<id> for
videos only mentioned via playlist in that realm. We also want to show
a realm with a playlist block as a "referncing realm" in the "my videos"
section, and we shouldn't show the "unlisted" note in case a playlist
block exists for a video. With that, it's most consistent and easiest
to explain if playlist blocks make events findable.

---

Also, this is already the behavior in code! Only the docs were wrong
about this. So this change isn't even breaking, it's just a doc fix.

[owi92]

👍