fix(dxt): apply user_config settings to the server

[aaronjmars]

What was broken

The Claude Desktop DXT handed its settings (WebSocket Port, HTTP Port, Auto-Tunnel, Safety Mode) to the server as WS_PORT, HTTP_PORT, ENABLE_TUNNEL and SAFETY_MODE env variables. server.js never reads the environment, only command-line flags, so every DXT setting was silently ignored: the server always started on 5555/5556 with no tunnel. Safety Mode had no server code at all; it only exists as the extension popup toggle. The committed opendia.dxt was also a stale 1.0.5 build.

What changed

Server (opendia-mcp/server.js)

• Reads OPENDIA_WS_PORT, OPENDIA_HTTP_PORT, OPENDIA_ENABLE_TUNNEL (1/true/yes, any case) and OPENDIA_TOKEN as fallbacks.
• Flags always win. --port still sets both ports (http = port+1) and overrides both env ports.
• Env ports use the same validation as the flags, so a bad value exits with a usage error (OPENDIA_HTTP_PORT=0x1f is not a valid port ...).
• OPENDIA_TOKEN feeds the same path as --token=, so it only applies when a token is required (tunnel or non-loopback bind).
• An empty value counts as unset. So does a raw ${user_config.x} placeholder, because some hosts pass an unset optional field through unsubstituted (fix: resolve user config placeholders modelcontextprotocol/mcpb#252). A blank optional field can never become the token.

DXT manifest (build-dxt.sh)

• Env keys renamed to the OPENDIA_* names.
• Removed the safety_mode setting and SAFETY_MODE env, since they never did anything. The field descriptions now say Safety Mode is set in the extension popup.
• Added an optional, sensitive auth_token setting (Tunnel Auth Token) mapped to OPENDIA_TOKEN. Leaving it blank keeps the old behavior: a fresh token is generated and printed at startup.

Extension (popup + background)

• New Custom HTTP Port number field in the popup, saved to storage.local.customHttpPort (blank clears it, invalid input reverts).
• Port discovery probes that port first, then the built-in list (no duplicate probe). Saving it triggers a rediscovery if the extension is not connected.
• Both builds share src/, so Chrome and Firefox both get it. Storage is read with the promise form, which works on Chrome MV3 and Firefox's native browser.*.

Tests, docs, build

• New opendia-mcp/test-config.js (env ports, flag precedence, bad env ports, tunnel and token from env, blank or placeholder token). It runs in npm test and as a new CI step. test-connection.js now checks that the custom port is probed first. test-helpers.js startServer accepts args/env.
• README documents the env variables, the DXT settings and the popup field. The extension README covers the discovery order. There is also a CHANGELOG entry under Unreleased.
• opendia.dxt is not rebuilt here. A fresh build is 36 MB (vs 12.7 MB) because build-dxt.sh bundles the extension source plus both dist/ builds, each with logo.mp4; the bundle gets slimmed and rebuilt in a follow-up PR.

No version bump; recent fix PRs (#82, #83) did not bump either.

How verified

• npm test in opendia-mcp: protocol, connection (including 3 new custom-port checks) and 16 new config checks all pass.
• By hand, with random high ports:
  • OPENDIA_WS_PORT=46162 OPENDIA_HTTP_PORT=46163 node server.js -> /ports returned {"websocket":46162,"http":46163,...}
  • Same env plus --ws-port=46172 --http-port=46173 -> Ports resolved: WebSocket=46172, HTTP=46173
  • OPENDIA_HTTP_PORT=0x1f node server.js -> OPENDIA_HTTP_PORT=0x1f is not a valid port (expected an integer 1-65535), exit 1
• Started the bundled DXT server with DXT-style env (including an unsubstituted ${user_config.auth_token}). It bound the env ports in local mode.
• Extension: npm run build, node build.js validate and node test-extension.js pass. web-ext lint shows 0 errors and the same 3 warnings as main.

Fixes #85