If you’re brave enough, I guess you could just switch to the candidate release channel, see Versions & Releases — Syncthing v1 documentation. Then report anything that seems odd.
Otherwise, I hope I’ll remember to ping you if something needs additional thorough testing ahead of a release.
One minor issue I just noticed with this approach: If we were to tag v1.19.2-rc.1 coming up, then no new API breaking changes (or even additions, such as gui, lib/model: Mark folders unaccepted by remote device (fixes #8202) by acolomb · Pull Request #8201 · syncthing/syncthing · GitHub will be allowed. Otherwise we would have to bump the minor version component post-RC to v1.20.0-rc.1?
I keep saying that the rc.2 release gets cut from a point which is equal to or after rc.1, but before any scary, large, or breaking changes. In principle it should be bug fixes only, but we haven’t enforced that strictly. Obviously API breakage is out of the question.