Support multiple active mcp-remote servers

[emilisb]

This is my attempt to solve #25

I found 2 main problems that were causing issues with multiple mcp-remote processes.

I already described the problems in the issue ticket but I will repeat myself here as well (with some updates to my explanation):

Issue 1

Preconditions:

• User is not authenticated yet.
• No lock file, no tokens file.
• No active mcp-remote processes running.

1. When the first mcp-remote process is started, the auth http server is listening on port 3334 (default).
   1.1. A new lockfile is created (with current timestamp and port 3334).
   1.2. Auth flow starts and new token files are written to disk.
   1.3. client_info.json contains callback url http://127.0.0.1:3334/oauth/callback <- please pay attention to the port being 3334 here.
2. When additional mcp-remote processes start, they check for an existing lock file. If the lock file is valid, auth flow uses the original process (using port 3334). Everything is working fine here.

The tricky part begins when more than 30 minutes have passed since the original process start time. Lock files older than 30 minutes are considered invalid (link to code), therefore a new lock file will be created. However, this time the port might not be 3334 - if the original process using 3334 is still running, the process will choose a random port and this new process will become the new "master" process (responsible for auth of other processes).

The problem is that now the new process has a different port than the previous one, therefore the new callback url is different. However, client_info.json still contains http://127.0.0.1:3334/oauth/callback. This causes oauth token verification to fail on the remote server and you can no longer connect to the MCP server until you remove old tokens from ~/.mcp-auth.

To fix it, I removed the 30 minutes timestamp limit - I believe pid + port checks might be good enough. @geelen do you remember if there was any specific reason for this check?

Issue 2

Preconditions:

• User is authenticated and a valid auth token is saved to file.
• No active mcp-remote processes running.

1. The initial mcp-remote process is created (on default port 3334) - we now reuse the previously created tokens.
2. From now on, all future mcp-remote processes will fail to log in because authCompletedPromise is never resolved.

authCompletedPromise is not resolved because the first process already had valid auth token, therefore /oauth/callback was never called.

[clouatre]

Hi! I have PR #175 which also addresses issue #25, but solves a different aspect of the problem.

This PR (#39): Fixes lockfile coordination issues (port changes, timestamp limits)
My PR (#175): Fixes OAuth cache collision for multi-tenant configurations (same server URL, different --resource flags)

Both PRs are needed for a complete solution to #25.

Good news: No merge conflict! My PR changes getServerUrlHash() signature but the new parameters are optional, so your existing calls will continue to work:

// Your PR calls (still works):
const serverUrlHash = getServerUrlHash(serverUrl)

// My PR calls (with additional params):
const serverUrlHash = getServerUrlHash(serverUrl, authorizeResource, headers)

Both PRs can merge independently. Users who need both fixes will get the full solution once both are merged.