Warning: This is going to be a bit free-form...
I think there are 2 ways to look at your concern.
If you think of it, some space shuttles and satellites have been running the same code that originally launched them. On the other hand, some have been designed to be updated even if they are (very) remote.
What matters is the environment. Obviously, as long as you don't modify the environment, your code won't become obsolete. In this instance, code rot doesn't really exist: the code itself (or the produced binary) cannot rot. It might break if you just start attacking it from a completely different angle. It's not that it's rotting, it's that it's not adapting to its environment. Think of it as an evolutionary problem.
But our environment changes. And somehow, what is the key to your problem is also the solution. Our environment changes so fast, that nowadays we wouldn't expect a software solution to not evolve over time. We overlook software projects that have not been updated in the past year, and will moan about product and customer support that doesn't produce a clear roadmap. And even when this works out well - you get a clear roadmap, good support, regular updates... - there's always the chance now that a challenger will surface, with exponential growth. We often make the mistake of thinking that the big established companies will always dominate, exactly because they dominate. However, the same way the dominant element in a herd gets older, the super-massive software/hardware/whatever vendor gets older. Or just a bit lazy. And a challenger comes in and turns things around even faster than the established dominant might have done it 5 or 10 years before. Or the dominant will just take a good beating, barely surviving while we see a disruption in the market (economically speaking, with impacts on different fields), and then things will go on. Maybe that looks imperfect, but in itself it's an organic process.
So, from the perspective of the user, I guess the issue is not that big. Code rot won't happen from the user's perspective, as he'll get to use an alternative (possibly with a seamless transition/migration... hopefully).
Now assuming we're not seeing things from the point of view of the user, or that we are talking about a system that is immune - for reasons unknown, governmental development, spac travel, etc... - to competition and is really supposed to be built to live/survive for a very long time, we need to look at the texts you referenced. And probably some more literature on dependable systems and fault-tolerant system. Though we probably want to push further. We don't just want fault-tolerance, we want evolutionary systems.
The problem with evolution, is that it introduces changes, and changes introduce points of failures. Let's look at these now and at what we can do to address them.
We can still rely on the infrastructure/architecture/emgineering metaphor while we do so (after all, we all ourselves software engineers, though there's arguably no such thing as software engineering... for now). There's a reason while the tube system is still active (with some glitches), while Big Ben still works (with some glitches) or the Eiffel Tower is still standing. It's because we do with vital (or not so vital) elements of an infrastructure what we should be doing with software just as well: continuous inspection. These entities were not necessarily designed to last this long, but have benefited from permanent oversight and timely improvements and repairs when it was needed. Call that your hotfixes if you will.
On the other hand, some designs were meant to last, and run durably with no interruption, even knowing that continuous inspection won't be possible. In this case we turn towards good design and formal models. Elements of dependability (Availability, Reliability, Safety, Integrity, Maintainability) can be quantified - for a given environment. Stats do the rest to plan for the rest and the future. Which brings the question: is it even possible for us to build systems that will be evolutionary, in the real sense?