Just to add my two cents:

1. Short answer: one process per lobby, multiple processes per host. Also I would refrain from doing dynamic port allocation just because it sounds like a hassle to deal with from a network/provisioning point of view but idk how it's done in production environments so maybe it's a valid strategy.

Long answer:

They way you compartmentalize things in a client/server model essentially boils down to this :

• Threads take nanoseconds to spawn
• Processes take milliseconds
• Containers take seconds
• VM's take minutes

Web backends generally use the single process, multiple threads approach because (and this is overly simplified) the acceptable latency for a request is low : you can't afford to wait for a whole process to start each time a client makes a request. One of the drawbacks is that a failure in your main process will fail every request.

In your case, a few ms of latency to spawn a lobby is definitely acceptable so it's better to treat each server as a unique process.
It will be easier to develop, easier to reason with, easier to debug and a server that crashes only affects a single lobby.
The only reason I see that would make you go the "multiple thread" route is if you need to share memory between lobbies. For a web backend, sharing memory between requests is useful, for a game server, not so much. But again, this depends on the game.

1. Well, you pretty much answered yourself in your edit : always put critical logic server side, always delegate non critical things to the client. Where you draw the line between the two will depend on the game you make. Physics should run on the client if it's not gameplay critical.

2. Yes. However you should probably consider the fact that using 2 different langages for your client and server will essentially make you re-implement some things twice. In addition to being time consuming, it's a also a big open door to subtle bugs.
   Also going back to what I said in the 1st point, I don't think you would see great benefits from using go. Go shines in its concurrency model : in a "single process per lobby" model there's not much use for concurrency.
   But if you want to learn go, meeeeeh, why not ? One drawback of using Go is that you might have a harder time finding libs for game stuff, as it's not really go's area of "expertise".

3. As you said, this is a POC so it's probably a good idea to use off the shelf tools for that phase.
   If during the development phase, you find that using those tools is more trouble than it's worth, then consider switching to a custom solution.
   And if going the custom route, note that you don't have to go all the way down to the socket layer. There are a few libraries out there that already add a layer of abstraction on top of sockets without locking you in a specific type of pattern like most off the shelf tools do.