lark-cli enters Hermes context when HERMES_HOME is inherited, then bind ignores HERMES_HOME path

Summary

After installing Hermes, unrelated CLI/automation processes that happen to inherit HERMES_HOME start failing when running lark-cli.

lark-cli detects a Hermes context and refuses to use the existing local lark-cli config, returning:

{
  "ok": false,
  "error": {
    "type": "config",
    "subtype": "not_configured",
    "message": "hermes context detected but lark-cli is not bound to it",
    "hint": "read `lark-cli config bind --help`, then ask the user to confirm intent and identity preset..."
  }
}

However, when trying to bind Hermes explicitly, lark-cli does not appear to use the HERMES_HOME path that triggered Hermes detection. Instead, it looks for a different default path:

{
  "ok": false,
  "error": {
    "type": "config",
    "subtype": "invalid_config",
    "message": "failed to read Hermes config: open C:\\Users\\example\\.hermes\\.env: The system cannot find the path specified.",
    "hint": "verify Hermes is installed and configured at C:\\Users\\example\\.hermes\\.env"
  }
}

In this environment, HERMES_HOME points somewhere else, for example:

HERMES_HOME=C:\Users\example\AppData\Local\hermes

Expected behavior

If lark-cli detects Hermes because HERMES_HOME is present, then one of the following should happen:

1. config bind --source hermes should read Hermes config from HERMES_HOME, or
2. lark-cli should not enter Hermes context unless Hermes config can actually be resolved, or
3. there should be a documented way to force normal local config mode, e.g. an env var or flag like --ignore-agent-context.

Actual behavior

Any unrelated process that inherits HERMES_HOME is treated as Hermes context.

This breaks existing lark-cli usage in non-Hermes automation tasks. Commands such as:

lark-cli auth status
lark-cli config show
lark-cli im +chat-messages-list --as user ...

fail before using the existing local config.

If HERMES_HOME is removed from the current shell, the same commands work again and use the normal local config:

Remove-Item Env:HERMES_HOME -ErrorAction SilentlyContinue
lark-cli auth status

Reproduction

1. Have a working local lark-cli config.
2. Install Hermes or otherwise set HERMES_HOME to a Hermes data directory.
3. In a non-Hermes shell or automation process that inherits HERMES_HOME, run:

lark-cli auth status

4. Observe hermes context detected but lark-cli is not bound to it.
5. Try:

lark-cli config bind --source hermes --identity user-default

6. Observe that bind looks for C:\Users\example\.hermes\.env instead of the path from HERMES_HOME.

Impact

This causes unrelated automation jobs that use lark-cli to fail after Hermes is installed, even though those jobs are not Hermes jobs and already have a valid local lark-cli config.

Version

lark-cli version 1.0.51

Start by reproducing the issue with HERMES_HOME set, then trace the lark-cli Hermes context detection and the config bind --source hermes entry points. Compare the path used for detection with the path used when reading Hermes config. Done means unrelated commands retain local-config behavior or explicit Hermes binding uses HERMES_HOME, with the chosen behavior covered by tests.