Not mentioning in this comment when the issue was fixed--two weeks ago in the code and days ago in production--is extremely dishonest. I have been contacted by literally everyone I have sent this to saying something akin to "dude says it was fixed quickly but they just didn't close the issue" despite my message with the link saying (exactly) "again point out "closed today, but only fixed in production last week" (fixed in the code two weeks ago, but that doesn't matter much)... at which point they are forced to do a double take and suddenly care.
I have worked on high-impact open source software--the iOS jailbreak ecosystem, writing some of the most core software for it, such as the mechanisms which support runtime code modification and which install the userland--with a much smaller team than Signal, and when you run into serious issues you need to disclose them, and you need to be super honest about the post-mortem. You shouldn't just kind of sweep the issue under the rug in the hope you can fix it before someone notices or it affects enough people to become a PR problem.
(On what is maybe a side note of my thesis here for a moment, but for completeness on the related issue of why I am so dissatisfied with these PR-like responses: you say it is "extremely rare", but not so rare that tons of people aren't reporting the issue happening at least to people they know; this is being used here as an excuse for why it was hard to find and fix, but is then being taken by some as "oh it was also unimportant": issues have to be additionally weighted by their impact, and this bug was clearly critical.)
The equivalent of this sort of thing I have run into is "there is like a one in a hundred thousand chance that you will experience catastrophic data loss from using my software", and I took those issues very seriously, as when you have tens of millions of users that's still a non-negligible number of people in the absolute: I considered every single person who would lose something like their camera roll on their phone to be a crushing defeat that I should internalize and take super personally, as I know the feeling of loss of important information and have enough empathy to assign it to my users.
(Hell: one time I actually hired someone to spend a bunch of time going back and building a tool that would take videos recorded by Cycorder (my video recorder for the original iPhone) that had been damaged by a bug I found in one version of the app that had led to some videos being misrecorded and lost--in a way that I think was even more random than "merely" if the power ran out while recording?--and repair them, to send to the almost no people who had taken videos of their family they realized only after an event weren't playable. This is different, of course, as this was after the fact, but a demonstration of the empathy I feel developers should have for their users: if I can do it with the tiny resources I had... anyone can do it.)
When you find reports of such an issue, you carefully track every single one of them down... but you also have a small time box, past which you need to disclose the issue to everyone: you put a large message on the download link of the product or update the homepage of the app to explain your status finding the issue and asking for help with leads, as it is important that people know that if this could affect them they can mitigate... maybe they don't send photos to anyone they couldn't afford sending to someone wrong, they use a different tool, or they switch to running Signal on iOS.
This doesn't seem to have happened? Hell: if anything, this issue seems to have been sufficiently boring to you that you didn't even close it the second you fixed it or keep people abreast in the issue on GitHub of when they could expect the fix you committed to roll into production. This is both an unacceptable communication style and level of empathy for a product trying to be as important as Signal (though sadly not terribly surprising on either count... it is this same lack of empathy that springs up when Signal has database corruption issues or lacks export tooling or spends its time undermining the wrong opponents or throws in a cryptocurrency--which I should want to celebrate as I am in that space!!--built on DRM tooling and without any warning or thought as to what it means for the one open source secure messenger... sigh).