TLDR: from a theoretical standpoint counting the number of block encryptions for known plaintext attack, what's proposed increases security by less than 3 keys bits (or less assuming many messages). From a practical standpoint, what's proposed is pointless, because one layer of AES-256 is more than safe enough against all except attacks targeting the implementation rather than the crypto.
I'll assume the simplest: that the
aes_ctr.decrypt considered in the question are length-preserving, and perform the exact same thing.
That previous answer considered that the nonces for the three stages are identical. It makes the first and third layers cancel entirely, because XOR used to combine plaintext and keystream is associative, commutative, and XOR with a constant is an involution. $K_1$ has no effect on the final ciphertext!
The question now clarifies that the nonces are independent, thus this cancellation occurs only if the first and third nonces happen to be equal. This occurs with probability 2-128 at each use, and detectably so. In that case, we are back to attacking only the center key $K_2$.
Independently: 5 blocks of known plaintext (80 bytes, that is like a line of text) is enough for a meet-in-the-middle attack. It builds a table of the values of the center pad XOR plaintext XOR ciphertext over 3 blocks for all values of $K_2$, then tests a value of $K_1$ with typically 4 or 6 AES block encryptions and a fetch of that table. The extra 2 known plaintext blocks allow ruling out false matches with negligibly little extra work. From the standpoint of brute force, security is improved only by a small factor (<6, thus less than 3 keys bits since 6<23) compared to a single layer. Methods exist to vastly lower the required memory.