I think I misunderstood your comment about markdown and react together, I didn't get that you were referring to nesting them two levels deep like that. It makes more sense that that's a pain - for what it's worth, in my non-web content authoring I do a lot of embedding LaTeX in markdown and it can become a bit of a mess.
The boundary between a 'headless cms' and a 'static site generator' can get somewhat fuzzy. The approach that I usually take here, when it's less of a hobby project, is to use a full-featured-editor-included CMS and then aggressively cache the pages so that behavior is just delivery of static files in the 99% case. This is an extremely common pattern with WordPress, for example---I would never call WordPress a paragon of performance but it is quite fast with the commonly used caching plugin that essentially reverts it to a static site generator for common cases. It's even better to do the caching in a web server or other in-between layer which is generally going to be faster at shuffling files than whatever language your CMS is in.
When it comes to simpler options with TS, I would just write what you need in bare TS. That gets you the advantage of typing without the weight of a framework. It does make it more difficult (though of course not impossible) to rely on framework components but I don't feel that really need them in your use-case.
Finally, totally with you on relying on the file system as a CMS. In my case I actually use the file name verbatim as the post title, one of those things that seemed too simple to work up front but is actually basically fine. The only constraint is that "titles" (e.g. file names) must start with the date because I just sort them to order posts - this is all so that posts can just be plaintext files (or markdown files, but I stick to plaintext as a stylistic decision) without needing to be parsed for any kind of header metadata or something. It is a limitation but I'm pretty happy with it a self-imposed one.
I also, to be fair, have a bit of a negative gut reaction to React in this kind of situation. In my line of works (operations or, to be more fashionable, DevOps), I have had more encounters than I can easily count with "react apps that should be static files" and are significantly more complex to deploy and maintain than they ought to be as a result. There's nothing like fighting with the TypeScript compiler in the build chain for, well, a static file. I'd be less harsh on this if I hadn't also experienced so many cases of developers shrugging when it ends up doing something undesirable, because they don't even understand the React part of it all well.
I'm not really convinced that it can deliver faster development but I'm also not unconvinced. I am pretty convinced that it ends up adding significant complexity that can really bite you when you encounter what ought to be trivial problems, and there's such a large push towards "batteries included" frameworks in JS, combined with the very fast turnover in popular frameworks, that it seems excessively common for developers to be building on top of a framework that they don't really understand well (because they just learned it and it does a lot under the hood) and that just has rough edges to deal with (because it's relatively new). It's enough to make you a little bitter after growing up on Python and, of all things, PHP, where frameworks and libraries tend to stick around for a long time, most developers have longer background with the language and framework, and the build-test-deploy toolchains are generally simpler. Not necessarily easier to use, but simpler---these two do not necessarily come along with each other, see 'create-react-app' and its 'eject'... a solution that is easy to use but so complex that it has a tendency to explode when you look askance at it.