Without wanting to be unkind, this author misunderstands the purpose of the exercise, which is to demonstrate to another human being that you can write code that meets the company's standards (as in, would pass PR review), not to ship a fully-functional product solo. The initial email makes it explicit that they don't care if the product even works ("Can use a fake backend") and that the specifications are deliberately open-ended. A little intuition and empathy can tell you that they probably are not going to spend many hours reviewing a complex submission, so the project should optimize for demonstrability of code quality, not completeness.

"I would like to know what kind of response I could expect..." - This is also established from the beginning: you can expect either a "Looks good, let's do some interviews" or a "Sorry, not interested," based on the code you submit. They can't narrow down the choices prior to your submission, because they're grading your submission, not your proposal document with an extensive list of details that they already told you they're mostly ambivalent to.

"So it is funny that my project is so weak, yet it made them update the guidelines to something stricter." - Main character syndrome. As someone who has been on the other side of these kinds of reviews, the far more likely explanation is that they kept getting submissions where the build instructions didn't work (which is not disqualifying by itself; the authors may not be on the same OS as the reviewers) and they got tired of spending time dealing with it.

Ultimately, the failure here was not a technical one but a social one. The author tried very hard to do the thing that it seemed like they were asking for, not the thing they actually wanted. The hiring manager's unwillingness to engage with the proposal doc was itself a form of communication that they were not interested in this level of detail, it was just an implicit one.

It's common for engineer types to want all that kind of communication to be explicit, and I have a lot of sympathy for those folks, but the reality is that teamwork is a skill, and the ability to suss out what a stakeholder actually wants, but isn't saying due to incomplete information and/or office politics, is a reasonable thing to select for. The ambiguity of the prompt is a feature, not a bug: it's kept the author away from a company whose communication style they're not compatible with.

(that said, this project does sound excessively complex for a take-home)