There's a flaw in that reasoning...
Actually, now when I think about it, your algorithm is much worse than that. Since you only encrypt a byte at a time, and the sequence of random numbers is fully known, you effectively only have a 8-bit XOR cipher. Not only is brute force viable, but even manual brute force BY HAND is viable since you effectively only have an 8-bit key and thus 256 combinations to manually examine.
Think of the "one time pad" encryption scheme. In the one-time-pad scheme, you have a seemingly random sequence of essentially infinite length to encrypt the data with. Now, you need only encrypt one byte at a time, heck even 1 bit if you like, and this is known to be uncrackable. It's essentially a key of infinite length, or rather the key is as long as the data.
Now relating that back to the proposed scheme here...
The sequence of random numbers is only "fully known" in the sense that the PRNG does eventually repeat its sequence, and so the key length is not infinite. But with the PRNG chosen here, that sequence is extremely long, and would not repeat for the length of the data being encrypted, making it effectively as secure as the one-time pad in that respect. However, the weakness is that where is starts has 2^32 possibilities. Basically you don't really know the sequence at all, but you it is one of X possible sequences.
Calling it effectively an 8-bit key is thus very much incorrect. Your earlier post about the key being 2^32 in size was correct though, because it's like choosing between 2^32 keys of a very long length.
Oh and this entire idea is not new to me, not in the slightest, although I never did bother implementing it yet.
Personally I would use a larger seed. Good PRNG algorithms have an internal state that is much larger than 32-bits. XORShift for example has 128 bits internally, and I'd probably use that and initialise all 128 bits to a 128-bit hash of the password, if I were doing this.
I'd also XOR 32-bits at a time, not because it's more secure, but because it's more efficient.