Make executor pair read the running server's keys without creating new ones

[tlq5l]

executor pair sends the API key saved in its data directory to the server on 127.0.0.1:<EXECUTOR_PORT>. It loaded that key through the same startup path as serve, so in a directory with no saved keys it created the directory, a pending installation record and new keys, then reported the generic "Executor could not start" message when the server rejected them. The released CLI uses ~/.executor/v2/cli as its data directory and the desktop app uses its own app data folder, so pair run beside the desktop app's server reads a different folder. This is the likely cause of #2178.

pair now only reads saved keys. It creates no directory, record, key file or OS credential, and takes no lock; a running server holds none after startup. A directory without saved keys is refused with "

has no saved keys. Start Executor first, or set EXECUTOR_DATA_DIR to the folder the running server uses. No new keys were created." When the request fails, it says whether no server answered on the port or the server did not accept the saved API key. Supplied EXECUTOR_API_KEY and EXECUTOR_ENCRYPTION_KEY still work without a saved directory.

Validation: the new local scenario starts serve with its own folder, then pairs from the same folder, from an empty folder (refused, folder stays empty) and against a port with no server. It fails without this change, where pairing from the empty folder created keys, and passes with it. Formatting, oxlint on the changed files and the typecheck pass.

local-pair.spec.ts

Fixes #2178

[RhysSullivan]

Thank you for this fix and the clear write-up! Your diagnosis was right. We've ported it into our main repository with a few changes. pair now shares its key-reading code with startup and rotate-key, and needs only the API key. It reports the server's answers through its own error type, and it also explains a rotated key, supplied keys and a service on the port that isn't Executor. You're credited as a co-author on the commits. v2 is exported from that repository, and the export merged this PR. It's in 2.0.0-beta.15.

Sent from my Claude