It's bounded, because the underlying DEFLATE algorithm has the maximum compression ratio of 1032:1 [1]. You still need at least one literal code and end-of-block code, but the former can be encoded in a separate block so you can indeed use only two bits per each run of 258 bytes.

At one point you will be also bounded by the maximum size of IDAT chunk, which is 2^31 - 1 bytes with a 4-byte-long chunk name included, and after that point you will constantly need 12 bytes of overhead for each additional 2^31 - 5 bytes. And we will eventually hit the maximum permitted dimension of (2^31 - 1) by (2^31 - 1) pixels. Since the long-term overhead (12 bytes) is much smaller than the one-time overhead (>50 bytes), the biggest image will result in the best ratio. Such biggest image needs at least N = (2^31 - 1) * (2^28 + 1) uncompressed bytes of IDAT, as each scanline needs one filter byte and 2^31 - 1 bits pack into 2^28 bytes.

We can now compress them down to ceil(N / 1032) compressed bytes plus small overhead, which should be divided into ceil((ceil(N / 1032) + eps) / (2^31 - 5)) = 260,112 IDAT chunks. Each chunk of 2^31 - 5 bytes contains at most ceil((2^31 - 5) * 1032 / (2^28 + 1)) + 1 = 8256 scanline boundary, which consists of one filter byte and one unused padding bit. Therefore we should have (2^31 - 5) * 1032 * 8 - 8256 * 9 uncompressed bytes (i.e. pixels) per each chunk, giving the upper bound of ~4127.99997308 pixels per byte. The actual value will be very slightly lower than that due to the one-time overhead---aforementioned significant digits did account for this.

[1] https://stackoverflow.com/a/16794960

Great answer. And sure enough there is a PNG bomb created by someone on the internet. PNG that renders to 225000 х 225000 pixels (50 gigapixels).

You can get 636 pixels per byte with a 256x256 pixel, 103 byte image. For example: https://www.mjt.me.uk/posts/smallest-png/

And they're used in real production systems :)