Upload error toast for a rejected presentation can't be dismissed and keeps reappearing

Describe the bug When bbb-web rejects an upload for exceeding maxNumPages, the presenter sees the upload-error toast. Closing it doesn't stick: the toast comes back on later re-renders for the rest of the meeting. Reloading the page doesn't help, because the flag the client checks is stored on the server. Only ending the meeting clears it.

Cause, from the code on v3.0.x-release (also present on v4.0.x-release):

1. The toast lists every pres_presentation row where uploadCompletionNotified = false (presentation-uploader-toast/container.jsx).
2. Closing the toast sends presentationSetUploadCompletionNotified. SetPresentationRenderedInToastPubMsgHdlr updates the row only if PresentationPodsApp.presentationBelongsToMeeting(state, presentationId) is true, which checks the in-memory pod state.
3. A rejected upload is never added to the pod state. PresentationConversionUpdatePubMsgHdlr writes only the DB row, and PresentationPageCountErrorPubMsgHdlr does pres <- pod.getPresentation(id), gets None, and leaves the state unchanged. It still writes uploadErrorMsgKey to the DB through PresPresentationDAO.updateErrors.
4. So presentationBelongsToMeeting is false for the rejected presentation, the notified flag is never set, and the row stays in the toast list. allPresentationsDone is false while that row exists, so the toast's effect sets showToast back to true on the next render.

PresentationUploadedFileTimeoutErrorPubMsgHdlr, PresentationUploadedFileVirusErrorPubMsgHdlr, PresentationUploadedFileScanFailedPubMsgHdlr and PdfConversionInvalidErrorSysPubMsgHdlr use the same pod.getPresentation(id) pattern, so the same thing probably happens whenever any of those errors arrive before the first page starts converting. Not verified for those paths.

To Reproduce Seen in production. Not yet reproduced in a lab.

1. As presenter, upload a PDF with more pages than maxNumPages.
2. Wait for the "exceeds the maximum number of pages" error in the upload toast.
3. Close the toast, or clear the error in the upload dialog.
4. Trigger a client re-render, for example another participant starting a webcam.
5. The upload-error toast reappears.

Expected behavior Once the presenter dismisses the error, it stays dismissed.

Actual behavior The error toast keeps reappearing for the presenter for the rest of the meeting.

Evidence from the production meeting

• bbb-web logged num_pages_exceeded for two uploads (288 and 299 pages, maxNumPages=256). The presenter then uploaded shorter versions, which converted normally.
• In akka, the IDs of the rejected presentations appear only in PresentationConversionRequestReceivedSysMsg, PresentationConversionUpdateSysPubMsg and PresentationPageCountError{Sys,Evt}Msg, all within about one second. There is no PresentationPageConversionStartedSysMsg, the handler that adds a presentation to the pod state.
• About two and a half hours later, the customer reported that the errors were still reappearing whenever someone turned on a camera. The link to webcam start comes from that user report. We have not isolated which re-render triggers it.

Possible fix Either let SetPresentationUploadCompletionNotified update rows that exist only in the DB (scoped by meetingId, which the DAO update already filters on), or have the error handlers add the errored presentation to the pod state when getPresentation returns None. The first is smaller. The existing permission check in the handler would still apply.

Server BBB 3.0: bbb-apps-akka 3.0-399, bbb-html5 build 1679. Presenter browser unknown.