If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case.
From a game theory perspective it doesn't make much sense for us to wait for the day where it is public knowledge that a QC exists. Given QC attributes as crypto-breaking machines, there's a history of similar crypto-breakthroughs remaining hidden.
It seems very unlikely to me that a QC will be created, then the tech will advance to the point that real-world keys can be broken in less than years, and all of this will be kept secret until it becomes an emergency. These government agencies are full of many people, and people are bad at keeping secrets. If this does happen, it can be survived due to the QC-resistance of Bitcoin addresses, but hurrying to plan for this seems like premature optimization. Especially when the current state-of-the-art in QC-proof signatures have
massively larger signatures than ECDSA, and bandwidth is currently a pretty big bottleneck.
There is a flag for disabling the RBF policy, -permitrbf=0.
IIRC the Core devs do have code prepared for adding QC-proof signatures to Bitcoin as a softfork (using a variant of Lamport signatures optimized for minimal size, especially in the scriptPubKey), though AFAIK this code isn't public.
