Fix local session continuation when API_SERVER_KEY is missing

[wangyanhui152-beep]

Summary

Fixes a local-mode session continuation failure where the first message succeeds but the second message fails with:

Session continuation requires API key authentication. Configure API_SERVER_KEY to enable this feature.

Root cause

In local mode, Hermes Desktop could attempt session continuation without a configured API_SERVER_KEY.

That created two failure modes:

1. The local Hermes gateway had no auth key configured, so continuation requests were rejected.
2. The desktop could still send a resume session id even when no auth header was present, which triggered the gateway-side continuation error.

Changes

• Automatically ensure a local API_SERVER_KEY exists before sending a local chat message
• Reuse the same generation/write path as the manual "Generate & save a key for me" flow
• Restart the local gateway after generating a missing key so the new value is picked up immediately
• Drop resumeSessionId when no auth header is available, so local chat degrades safely instead of forcing a continuation error
• Add regression coverage for the no-auth resume path

Why this helps

This fixes the confusing "first message works, second message fails" behavior for local installs that do not already have API_SERVER_KEY configured.

Tests

• npm test -- --run tests/hermes-api.test.ts tests/api-server-key-resolution.test.ts

[wangyanhui152-beep]

A bit more context from local reproduction:

I was able to reproduce this on a real local install where Hermes was running normally, but neither ~/.hermes/.env nor ~/.hermes/config.yaml had an API server key configured.

In that state:

1. the first chat message succeeds
2. the second message fails with:
   Session continuation requires API key authentication. Configure API_SERVER_KEY to enable this feature.

What makes this especially confusing is that the app appears functional at first, so this does not present like a normal setup/configuration failure.

I also checked the current README/docs and did not find a clear first-run requirement telling local users to configure API_SERVER_KEY before chat/session continuation will work, so this seemed better handled as a product-side guard rather than a docs-only fix.

This PR keeps the scope narrow:

• local mode only
• remote/SSH behavior unchanged
• auto-generates a local API_SERVER_KEY when missing
• avoids forcing session continuation when no auth is available
• includes regression coverage

I also verified the fix locally after applying it.

[pmos69]

Thanks for the PR. I think this is directionally useful, but I do not think it fully covers the continuation failure reported in #423 yet.

The missing-key case is handled here: if getApiServerKey(profile) returns empty, this generates API_SERVER_KEY, writes it, and restarts the gateway. That is good.

The remaining gap is the api_server.token-only case. In that case getApiServerKey(profile) returns a value, so ensureLocalApiServerKey() exits early. But the gateway may still not see API_SERVER_KEY, which is the mismatch behind the reproduced #423 failure: Desktop has a key, gateway logs "No API key configured", and session continuation is rejected.

Before merging this as a #423 fix, I think we need either:

• source-aware handling that ensures any resolved key is also gateway-visible, e.g. copied to .env as API_SERVER_KEY and/or injected into the gateway env, or
• a narrower scope/description saying this only fixes the "no API server key exists anywhere" variant.

The resumeSessionId guard is still a useful defensive change. I would keep that part: if there is no auth header, we should not force X-Hermes-Session-Id continuation and trigger the gateway-side continuation error.

Could you add a regression test for this case?

config.yaml has api_server.token
.env has no API_SERVER_KEY
local chat continuation should not fail with:
Session continuation requires API key authentication

Related note: #369 is still in the pipeline with a complementary, broader scope around source-aware key resolution, migration/injection, and config-health diagnostics. I do not see this PR and #369 as competing, but we should make sure the runtime fix here covers the same reproduced key-mismatch shape before we merge it.