Unhandled EADDRINUSE when the configured port is in use (multi-vault) — proposed fix + UX

[BozhengLong]

Summary

When the REST API server's configured port is already in use, _refreshServerState() calls server.listen() with no 'error' handler, so an EADDRINUSE surfaces as an uncaught exception and the API silently fails to start. This is easy to hit whenever more than one vault has the plugin enabled, because ports are a per-vault setting but every vault defaults to the same values (27124 / 27123).

Steps to reproduce

1. Enable the plugin in vault A (binds 27124).
2. Enable it in vault B (also defaults to 27124).
3. Vault B's server fails to bind — no user-visible signal, and an uncaught exception is thrown.

Why it matters

Multi-vault users get a silently dead API with no indication of what happened or how to fix it.

What I'd like to contribute

I have a fix ready (with tests; lint/typecheck/build green) and wanted to confirm scope before opening a PR, per CONTRIBUTING.md. The change has two layers:

1. Bug fix (core): attach an 'error' handler so EADDRINUSE (and other bind errors) no longer throw uncaught, and surface a clear message instead of failing silently.
2. Optional remediation UX: detect the conflict, probe for a free port, and show a persistent indicator plus a one-click "Switch to port N" button in settings (the two servers' suggestions are kept distinct). It deliberately never changes the default port automatically, to preserve the assumption that tools can rely on the default port.

Question

Is the full direction (bug fix + self-service UX) welcome, or would you prefer just the minimal error handling (layer 1)? Happy to scope the PR to whatever fits the project's goals. Thanks!