v0.3.2

Fixes openproxy server start --port N binding the wrong port.

What was broken

server start --port 4871 printed Starting openproxy on 127.0.0.1:4871, then linked Dashboard → http://127.0.0.1:4623 in the same run — and actually listened on 4623. When 4623 was already taken, it died with Error: Address already in use (os error 48) naming no port at all, so the natural read ("my port is ignored") pointed at the wrong thing.

Cause

--port was parsed onto the subcommand's StartOptions, which the banner and endpoint sidecar both used — but the foreground path then fell through to a boot loop that binds the global cli.port, still at its 4623 default. Banner, sidecar, and bind were three reads of two different values.

Fix

• The effective host/port is resolved once and carried onto cli before the fall-through, so banner, endpoint and bind can no longer disagree.
• Regression test pins the resolution rule (subcommand --port wins, otherwise the global stands).
• Mutation-checked against the real binary: reverting the fix reproduces the 4623 bind exactly.

The bare-flag path (openproxy --port N) was always correct — only the subcommand form was affected, which is why this survived to v0.3.1.

Upgrade if you run a second instance alongside a live one, or if you rely on --port.

Full Changelog: v0.3.1...v0.3.2