fix(portal): allow single-label container hostnames in private network validation

[elf-mouse]

When running under Docker Compose, internal upstream services (such as the authentication broker http://auth:8080) use bare single-label hostnames without dots (e.g. auth).

The previous isPrivateNetworkUrl check rejected any non-IP host missing a domain extension or .local suffix, causing portal boot checks to fail with a misconfiguration error.

This commit updates isPrivateNetworkUrl to accept single-label hostnames (!host.includes(.)) as valid private network hosts.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[rajpratham1]

This is a small, targeted fix that addresses a realistic deployment scenario without broadening the trust model in a concerning way.

What the PR does well
Fixes a real compatibility issue
Previously, only localhost, certain private domains (.internal, .flycast, .local), and private IP ranges were considered trusted.
This change additionally allows single-label hostnames (e.g. http://auth:8080), which are commonly used for service discovery inside Docker Compose, Kubernetes, and other private container networks.
Minimal change

The implementation is a single condition:

|| !host.includes(".")
This keeps the logic simple and doesn't affect existing trusted hostname checks.
Regression test included

The test adds:

http://auth:8080

ensuring this deployment scenario remains supported in the future.

Security considerations

I don't see this as introducing a significant security risk because:

The validation still requires an http or https URL.
Single-label hostnames are generally not publicly resolvable via normal DNS and are primarily used within private networks.
Existing checks for localhost, .internal, .flycast, and RFC1918 IPs remain unchanged.
Minor observation (non-blocking)

Using !host.includes(".") also accepts any single-label hostname (e.g. printer, db, redis, foo). That is likely intentional for containerized environments, but if the project ever needs stricter validation, a comment explaining that this is specifically to support Docker/Kubernetes service names would improve readability.