See Slack thread for background.

There was an issue reported where the db_execute_query MCP tool failed with the following error:

Error: failed to connect to database: failed to connect to `user=tsdbadmin database=`: 
     /private/tmp/.s.PGSQL.5432 (/private/tmp): dial error: dial unix /private/tmp/.s.PGSQL.5432: connect: no 
     such file or directory

Given that the part in backticks doesn't include a hostname or database name, and the port appears to be 5432 (the fallback value), I believe this likely indicates that the service host came back from the API as the empty/zero value ("") and the port came back as nil, and we therefore built a connection string that looked something like postgresql://tsdbadmin@:5432/tsdb?sslmode=require. As a result, pgx tried to connect to a local unix domain socket, and failed.

This is similar to the error returned by psql when you try to use that same connection string:

$ psql postgresql://tsdbadmin@:5432/tsdb?sslmode=require
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

This PR updates the logic in GetConnectionDetails to check not just for a nil host, but also for an empty host (""), and return an error rather than trying to connect with the empty host. It also removes the fallback port logic, and instead validates that a non-zero port was provided. I don't believe there's realistically a case where we would fail to return a port in the "get service" response, and 5432 would just so happen to be the correct value to fall back to (but please correct me if I'm wrong about that).

This doesn't resolve or explain the underlying error (an empty host/port coming back from the backend), but it should at least make the source of the error much clearer if/when it happens again in the future, which should give us a better footing to investigate deeper.