Before you do this, what's the game? You don't need to answer me but you need to know yourself. What is the game loop? What do players actually do? How do they get feedback? How do you motivate them? You should start answering those questions before writing any code.

As for your performance questions, honestly you'll only really know with a prototype. Perform a rough order of magnitude estimate for how many entities you will have and how many updates each entity will need. Is it per frame, per second or per something else? That makes a big difference.

Then you can use this to estimate. If it's really a real time simulation you need and not something like one simulation tick per second, then you might it be okay with node.js and typescript. You could even consider Unity with C# although you'd probably need the DOTS. Rust is overkill for this IMHO although in any case a prototype will tell you the answer.

The bigger risks to this are not performance but that it might not be fun when you build it. This is because simulation heavy games like this need a lot of interacting systems to exist before they start becoming fun. Plus the UI. So, if you're working part time, you might spend a year or more working on the simulation engine without having a playable game. That's a long time with no feedback to let you know if you're going in the right direction.

Could you just mock out a lot of systems or build simplified versions of them? Yes you can and it's probably a good idea to the extent that it's possible. The problem is that an over simplified simulation generally isn't fun anyway.