But, at the risk of being repetitive, because maybe this simplifies things:
Generate a random 128 bit key by hashing something. This is what the Linux KRNG does with raw entropy.
Initialize AES-128 with that key and start running it in CTR mode. Encrypt a file with known contents, like /etc/ttys. That's ~1300 bytes of known plaintext.
Now, recover the AES-CTR keystream (just XOR /etc/ttys against the AES-CTR ciphertext).
Is it your contention that, having done that, you've placed yourself closer to guessing the underlying 128 bit AES key?
If not, you see also why drawing out 1300 bytes of Linux KRNG randomness doesn't help you predict future values. The randomness you read from /dev/urandom is fundamentally just PRF keystream.
If you could look at AES-CTR keystream and use it to make an advantaged guess at the underlying AES key, AES would be grievously broken.
This is correct if either:
1. the planet held enough energy to perform a brute-force attack on a 128-bit key (it doesn't: https://en.wikipedia.org/wiki/Landauer%27s_principle ) and such an attack could be performed while the protected information was still relevant. Or:
2. You have an algorithmic break on AES that allows the attack to be carried massively more efficiently, enough to make it practical.
Cryptographers refer to this situation as 'winning'.
Abstracting away a little bit. What is a block cipher? A bijective mapping between identical sets uniquely identified by the key. This makes it a permutation; and a good cipher says (among other things), that every key yields a unique permutation.
This doesn't mean that the mapping of one value identifies the key (i.e. the permutation itself). If the mapping for each key were truly random, then it would be essentially impossibly unlikely to end up not sharing a number of individual plain->cipher mappings between different keys.
You can do this as a little experiment using a small block size, 4 bits or so.
As long as none of the 128 bits of the plaintext is known, we're also adding 128 bits of unpredictability, so the net result is zero.
If some of the plaintext bits are known, in theory the unpredictability should decrease. For an extreme example: if all 128 bits of plaintext are known, and all 128 bits of ciphertext are also known, there should be a single 128 bit AES key that maps that input to that output, so the entropy left in the key would be zero.
However, there is no known way to find that single key other than through a brute force search through all the 2^128 keys, so it's still safe. That also applies to the CSPRNGs: even if the entropy has decreased to zero, as long as an attacker has to brute force through a large enough number of possible states to take advantage of that fact, it's safe. It doesn't change the fact that, when the entropy left is zero, there is a single state which could lead to the observed outputs.
Yes, this means that after the entropy in the CSPRNG has passed the point where brute force is no longer viable, the amount of entropy left on the pool becomes a useless measurement. What matters is how much work an attacker would have to do, not how much theoretical entropy is left.