[maksimu]

When a server rejects Commander's built-in transmission keys with key_id=-1, Commander now asks it once for its own key at GET /api/rest/server_public_key, which Self-Managed Keeper serves since smk#448. It registers the answer in Commander's key table and in the embedded KSM SDK's, then retries. Against SMK, login, slack-app-setup and service-mode docker setup no longer need KEEPER_SERVER_PUBLIC_KEY_ID/KEEPER_SERVER_PUBLIC_KEY. The env vars still work and take effect first.

Keeper's regions never answer with key_id=-1, so Commander never calls the endpoint against them. If the endpoint is missing or the call fails (404, non-JSON, timeout, an unusable key), Commander logs at debug level and falls back to the existing invalid_key_id error. Each server is asked at most once per process. The key is trusted on the same TLS verification as every other request to that server.

The unit tests cover the registration in both tables, the 404, non-JSON, network-error and bad-key cases, asking only once, an execute_rest round trip against a fake server with its own key (it fails with the old error when the fetch is disabled), and that a normal 200 never calls the endpoint. Not yet run against a live SMK.