fix: bind vs browser URL handling for remote access

[akolotov]

Picked from #37

This PR fixes startup URL handling when CodeDash is configured to listen on a non-localhost bind address such as 0.0.0.0.

From the user point of view, the issue was confusing startup output in remote-access setups. CodeDash could be listening correctly, but the printed address mixed together two different concerns:

• the address the server binds to
• the address a browser should actually open

This change separates those two concepts explicitly. The server still binds to the requested host, while the startup output and browser-facing URL stay usable for the machine that launched CodeDash.

Why this change is needed

In remote-access mode, users can intentionally start CodeDash with a wildcard or non-localhost bind host so that other devices on the local network can reach it.

Before this fix, the startup path reused the bind host too broadly. That created two practical problems:

• startup output was less clear because it did not distinguish the real listen target from the user-friendly browser URL
• wildcard bind values such as 0.0.0.0 are valid for server.listen(...) but are not the right host to present as a browser URL

For users, that means CodeDash can appear misconfigured even when it is working. The app is listening correctly, but the displayed/opened URL is not the most usable or least surprising one.

Root cause

The startup logic treated the configured host as if it were a single canonical address for all purposes.

That assumption is wrong for wildcard bind hosts:

• 0.0.0.0, ::, and similar values are valid bind targets
• those same values are not the right browser-facing address to show or open locally

There was also coupling between the bind host and the base URL used for request URL parsing, even though that base is only a helper for parsing relative request paths and does not need to reflect the listen host.

What changed

• Added explicit browser URL derivation via getBrowserUrl() / getBrowserHost()
• Kept server.listen(...) on the actual bind address
• Updated request URL parsing to use a stable localhost base instead of reusing the bind host
• Updated startup logs to print both:
  • the effective bind target
  • the browser-facing URL
• Kept wildcard bind hosts browser-friendly by mapping them to localhost for display/open behavior
• Used execFile(...) for browser launch so the URL is passed as an argument instead of through a shell command string

Why this does not break anything

• Default behavior is unchanged. If CodeDash is started with the normal localhost configuration, it still behaves the same way.
• The HTTP server still listens on the exact configured host. This PR changes presentation and startup URL selection, not the underlying binding behavior.
• API routing and request handling are unchanged. The request parsing base URL is only used to parse relative paths, so switching it to a stable localhost base does not alter endpoint behavior.
• Wildcard binds become safer and clearer, not different in network semantics. 0.0.0.0 still means "listen on all interfaces".
• execFile(...) does not change intended behavior for opening the browser. It just uses the more appropriate process-spawn primitive for a fixed command plus arguments.
• No session loading, search, conversion, cloud sync, frontend rendering, or stored data paths are affected.

User impact

Before:

• users running CodeDash with a remote-access bind host could see startup output that was technically tied to the bind address but not ideal as a browser URL
• wildcard bind setups were more confusing than they needed to be

After:

• startup output clearly shows where CodeDash is bound
• startup output also shows a usable local browser URL
• wildcard remote-access setups remain reachable remotely while still presenting localhost for local browser use

Verification

• Run CodeDash with CODEDASH_HOST=0.0.0.0
• Confirm startup output shows:
  • bind 0.0.0.0:<port>
  • http://localhost:<port>
  • Listening on all interfaces
• Confirm the server is reachable locally on localhost:<port>
• Confirm the server is still reachable remotely through the host machine IP on the same LAN