NIST requires 128 bits of entropy to seed CTR_DRBG with AES-128, so you can safely assume that. If you ask for 256 bits of data, there is theoretically a chance that an attacker could be able to attack the RNG with a 128-bit attack:
Suppose a 256-bit random value is requested twice and the attacker sees the first one, which we denote by $x_1||x_2$ (two 128-bit AES outputs). Then they could iterate all 128-bit keys and pick the one(s) for which $D_k(x_1) + 1 = D_k(x_2)$ (there's at least one, probably not many). They can then predict the next state of the PRNG and its next output (as being derived from one of those matching states).
Of course, in practice a 128-bit complexity attack is not doable either, so you should be safe. However, strictly speaking you cannot assume you have 256-bit security with that key. At least unless you also assume no previous PRNG output has been seen by an attacker.
As an aside, this:
On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected.
is basically FUD. The output is no lower quality regardless of how much the entropy pool is drained. As long as enough entropy has been collected in advance, the state of the random number generator is unpredictable even if you request enough data to drain the entropy count. The pools are 4096 bits, which is way more than necessarily needed for a secure scheme.