fix: boot-time patch for Hermes ACP session restore with stale provider

[gitricko]

Summary

When the VS Code extension reloads, it tries to restore the previous ACP session. If that session used a provider no longer in the current config (e.g. "custom" after switching to "omniroute"), the runtime resolution returns an empty api_key and init_agent raises "No LLM provider configured". The session restore fails silently, and the extension never gets a response to new prompts.

This PR adds a boot-time cont-init script that patches the installed Hermes agent to retry session restoration with the current config provider when the stored provider fails.

What Changed

New file: docker/hermes-acp-patch.sh

A cont-init.d script that:

1. Checks if the patch is already applied (idempotent)
2. Finds the exact _restore() except block in the installed Hermes session.py
3. Replaces the single-attempt exception handler with a retry that falls back to the current config provider

The patch targets the installed Hermes at /usr/local/lib/hermes-agent/acp_adapter/session.py, which is placed there by the scripts/install.sh during Docker build.

How It Works

Original behavior (broken):

_restore() → _make_agent(stored_provider="custom") → resolve_runtime_provider("custom") → FAIL → raise → return None

Patched behavior:

_restore() → _make_agent(stored_provider="custom") → FAIL → _make_agent(current_config_provider="omniroute") → OK → restore session

Root Cause

The runtime provider resolver resolve_runtime_provider(requested="custom") returns an empty api_key when:

• No custom_providers.custom entry exists in config
• The host localhost does not match known provider host patterns for env-var key resolution

This causes init_agent at agent/agent_init.py:736 to skip the explicit-credentials path (if api_key and base_url: → api_key="" is falsy), fall through to the router, which returns None, and raise "No LLM provider configured".

Testing

# On a fresh container build, verify at boot:
docker logs webtop | grep hermes-acp-session-restore
# Expected: "[hermes-acp-session-restore] applied successfully"

# Idempotent (second boot):
# Expected: "[hermes-acp-session-restore] already applied -- nothing to do"

Durability

The patch is a cont-init.d script so it survives container rebuilds. If Hermes is upgraded (the scripts/install.sh installs a new version), the Python string match will fail gracefully with "patch site not found -- Hermes may have been updated" and a non-zero exit code. No silent corruption — just a log entry that the patch needs regeneration.