A parked upload has three ways to be released, and two were weaker than the
toast that promises "wird gesendet, sobald die Sperre aufgehoben ist":
* The live user-shown / event-opened events only reach a tab with an open
stream, and streams are opened by /feed, /diashow, /export, /host and
/admin — NOT /upload, which is exactly where the toast sends the guest to
watch their queue.
* The boot-time release ran once and swallowed any failure, so a single
failed request on venue wifi — the condition the whole parking mechanism
exists for — skipped it for the entire session, leaving the row reading
"Du bist gesperrt." after the ban was long lifted.
Now retried once. Deliberately NOT on a 401: api.get already answered that by
clearing auth and redirecting to /join, so a second attempt can only fire a
second redirect two seconds later, by which time the guest may have navigated
away. (That is not hypothetical — it made an existing browser-chaos spec fail
while I was writing this.) Guarded rather than an early return, so the SSE
listener registrations below still run.
Also: noteDelivered mapped upload-processed to p.id, but that payload carries
upload_id, so it recorded nothing — the docstring claimed a property the code
did not have. And it recorded user-shown against a `carried` clause that only
ever means "hidden", where it could only suppress a later genuine signal.
5aa2b2e886