Spaces in ASCII art rendered smaller on mobile browser

Google Fonts CDN is to blame here

Well the issue here is the Google Fonts (GF) CDN, as usual when it comes to even slightly unusual requirements (see notes). In this particular case, contrary to the intuition, it is not the "space" character what is "wrong" (the shipped web-font supports it), but the █ - this character is missing in there. Naturally, if you download the JetBrains Mono from the source, it will support said character.

So if we really need to use GF for ASCII-art, we must pick some font that supports used characters (or have the exact same metrics as the fallback fonts).

It seems that one such fonts with "full" full-block support is Cascadia Mono:

@import url("https://fonts.googleapis.com/css2?family=JetBrains+Mono&family=Cascadia+Mono");
body {
  background: black;
  color: aqua;
}
pre {
  line-height: 1;
}
[style]::before {
  content: attr(style);
  display: block;
  color: pink
}
@font-face {
  font-family: 'Middot';
  src: url('data:font/woff2;base64,d09GMgABAAAAAAEIAAoAAAAAAmQAAAC/AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmAANAoYNgE2AiQDBgsGAAQgBWAHIBvJAUCfB3ZMmCrCLiO6iyA6zNm7/U8vtCDp2rVU4E6dICBxDVj4q1Q9Pb5+838+HHRwPDhEAUaRYcCBFGBggYfsjWKTZRd1FT8GkiPAyRinSjkYjQMzAMoWCjR0LOsCy1IhpUCNpCwBoIFEiAGUnZFrUzH5Oz09DQSCgzM3d/g/Hk7hz3lqk2at2kTXQPB8X5k0aVUAAEJhUqBJARoAAIaudZETwjSbTTNN16wnM9A8w+dnXXn14MGbb/eu7OkKAAAA') format('woff2');
  unicode-range: U+0020;
}

█   █   █   █
█████████████

█   █   █   █
█████████████

█   █   █   █
█████████████

█   █   █   █
█████████████

Notes

GF's CDN often (but not always, to make things worse) ship butchered versions of fonts, with OpenType features removed, or with incomplete character sets, compared to the full-fledged originals. To make things even worse-r (eh), the initial preview usually loads the better (full) version of the font. See this filter and sample text, accompanied with devtools amendment

setInterval(()=>document.querySelectorAll('.tiletext,textarea').forEach(=>.style.whiteSpace='pre'),500);
document.querySelectorAll('textarea').forEach(=>.style.fontFamily='Cascadia Mono'); // reset to the system one, hopefully sane

Right off the bat, it is clear that Roboto Mono and LXGW WenKai Mono TC do not likely support needed characters. The JetBrains Mono looks promissing, but load its detail and start interacting with the specimen and you'll get familiar-looking:

More notes

The original code in the question includes a couple more nuances worth addressing:

1. pre gets own font-family from the browser

I.e. it does not inherit from body. Applying font-family to body leaves it's children pre unaffected, or more precisely leaves it to the default UA styles. In effect the bug we were dealing with here was more about Android default fonts, that just coincidentally exhibited very similar problem like the one in the GFs version of JetBrains Mono. This problem can be seen verbatim in the testing snippet above in this answer on any system (as long as Google won't fix and update their stuff.)

2. "ASCII-art" accessibility

Text drawings are notorious pitfalls for assistive technologies, and ideally should be treated like images with corresponding "plain-text" alternative. So all text content that is not intended to be read literally should be marked with role="img" attribute and corresponding readable transcript placed in the aria-label or similar:

 ####
######
 ####
  ##
  ##
  ##
  ##

See: https://www.w3.org/TR/WCAG20-TECHS/H86.html