> none of the line breaks will be rendered, and of course there'll be no interactivity
Not sure what you mean by no interactivity, but yes, you'll need to add stuff to README.txt.htm to make the content (incl. linebreaks) render ~identically to the way it renders when you view it as README.txt, but that's not a big deal. It's < 8 lines of CSS, and you can "hide" it in plain sight if you're clever about it. In reality, though, you won't need to worry about hiding it, because once something becomes convention, people will just scan past it—just like elements on any other Web page that has a familiar layout (e.g. a GitHub repo), or the frontispiece and recto in a book, for that matter.
> all that extra markup that markdown tries to minimise
You don't need a lot of extra markup. Just the `<script>` and `<style>` blocks will suffice. (And, again, only a brief one in the case of the latter. You want to aim for everything to be either readable prose in the vein of Markdown or readable code that intersperses the prose in the vein of the sort of code blocks that you get to use in programming notebooks.)
I have, in fact, already written programs like this. Here's an example of one written in that style (although it's not a README.txt.htm):
<https://www.colbyrussell.com/LP/debut/plain.txt.htm>
The trick is to remind yourself that you're writing for a technical audience who wants a thorough (but succinct) specification of the internal workings of the machine. Here's another example of writing in that style (although not using the "plain.txt.htm" trick):
<https://crussell.ichi.city/gpe.html>
(And there's actually nothing stopping you from writing a "plain.txt.htm"-style program that looks that way when you first open it, but also accepts some command or key sequence that lets you toggle between the plain and the "rendered" form that looks something like that Google Podcasts exporter example.)
> web browsers [...] are pretty heavily sandboxed to prevent running external binaries (e.g. gcc)
Welp, definitely don't expect to be able to (easily*) do this for projects that have GCC as a development dependency, but this article was posted by the web developer Chris Coyier on a site for other web developerscalled CSS Tricks. The long-tail of packages on NPM and other bundling tools that are such a mess and can't be expected to reproducibly build because they adhere to what are poor-but-typical development practices in that world? Very good candidates for this style. (It's almost inconceivable that that community managed to create an ecosystem that is as frustrating—if not more—as the experience that you encounter with trying to wrangle traditional/"native" toolchains—and yet they did.)
Moar on that topic can be found here:
<https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
* I will say, though, that I have managed to use a similar trick to write cross-platform build scripts that are able to compile Wirth's Oberon system, including the ability to produce a disk image for Peter De Wachter's Oberon RISC emulator