Thanks for the disclosures – Browsed over the Replacement Stalling Attacks one, if my memory is correct on this subject, I think Bastien Teinturier was the first back in 2021 sharing with few lightning devs the idea of “cat-and-mouse” attacks, i,e adversarially aggregating and disaggregating option_anchors second-stage HTLCs transactions. Sounds what you found is one variant of those “cat-and-mouse” attacks, but this is nothing very specific to LND.
About disclosure timeline, 90-days is generally the basic infosec embargo timeline. It can be a bit dry, assuming it’s a “simple” bug that can be fixed solely by the implementation (so no cross-layer vulnerability), letting a 4-6 months sounds more generous and in line with the usual release cycles of Lightning implementations. It’s really depends on the type of vulnerability, however the drawback with an isolated release with only 2 or 3 lines of changelog, with one altering some critical code paths, is to make it too much obvious there is “covert fix” somewhere and lowering the bar for any external actor to know what to look for to reverse-engineer.
On all the logic area you’re pointing you, i.e claimable outputs detection, generation of claims transactions, fee selection and scheduled rebroadcast of the claims of transactions, it has been floated few times the idea, at least since 2020, to write a specific BOLT encompassing all this flow with the do and don’t. While there is no necessity at all of inter-compatibility among the Lightning implementations on logic, despite being one of the most critical area for channels funds security, somehow Lightning implementations kept put one’s foot in one’s mouth on this flow. An (incomplete) experience has been attempted for the DLC spec on what such piece of recommendations can cover.
Otherwise, we can also keep eating popcorns and making laughs of Lightning implementations being insecure again and again on their on-chain logic management.