Let's pretend that a Quantum Computer that could break the encryption and steal Satoshi's coins is close to being built - in one year let's say, how long can the Core Developers code a patch and have it merged?
The simplest patch can be coded quite quickly. All old coins can be timelocked by consensus, up to a given block number. And then, a future soft-fork can decide, how these coins should be unlocked, by meeting old ECDSA conditions, and any new conditions, introduced by the next soft-fork.
It would probably fair to say that we are not ready?
Ready for what? There is a difference between bug like Value Overflow Incident, bug like SIGHASH_SINGLE, a weakness in ECDSA, which would allow getting private key after 2^80 operations, another weakness, which would allow going from any public to any private key instantly, a weakness in SHA-256, which would allow collisions, a weakness which would allow preimages, and so on, and so forth. For which attack do you want to be prepared? There is no tool, which can protect you from everything. Depending on a particular attack, it can be trivial to fix it, or impossible.
what should actually be assumed is every participant/entity should be acting according to their own incentives
Of course. But you don't have attacks, which breaks everything at once, and you don't have protections, which fixes all bugs at once. There are always particular attacks, and particular fixes. If you think, that SHA-256 is weak, then prove it, by claiming some of the puzzles (not necessarily created by me, because there are many others). If you believe, that there is not enough reward in existing puzzles, then put more coins in. And if you think, that existing scripts cannot measure the progress correctly, then make a better puzzle. A Script can do a lot of things, and even if it cannot, then still, you can write a version, where new feature is activated, and convince people, that a given soft-fork is needed. Or: you can make a sidechain, which can have any rules, and peg it into Bitcoin. And also, you can make LN nodes, which will execute existing rules, and also some new ones, which would be available only in L2, only between selected clients.