feat(config): support environment overrides for app profile and userOpenId in agent runtimes

Problem

AI agent runtimes such as Hermes/OpenClaw run as long-lived concurrent processes. A single process may handle requests from different Feishu/Lark users and sometimes different app profiles.

The current lark-cli config model can select a configured app/profile and may fall back to Users[0] for user identity. This is unsafe for agent runtimes because the active user must be selected per request, not by mutating global config or relying on a static default user.

For example, if user A asks an agent to read a document, lark-cli should use user A's user-access-token. It should not silently use user B from Users[0].

Proposed feature

Support environment overrides:

LARK_CLI_PROFILE=<profile-name>
LARK_CLI_AS_USER=<userOpenId>
LARK_CLI_REQUIRE_AS_USER=1

Suggested resolution priority:

Profile selection

explicit --profile > LARK_CLI_PROFILE > currentApp > Apps[0]

User identity selection

LARK_CLI_AS_USER > fail if LARK_CLI_REQUIRE_AS_USER=1 > Users[0]

Why environment variables?

Agent tool calls are often generated by skills, wrappers, or subprocess execution layers.

Requiring every generated lark-cli command to manually pass profile/user identity is brittle. A host agent needs a safe way to inject request-scoped identity into the subprocess environment without mutating global lark-cli config.

Environment variables allow the host agent to select the correct app/profile and userOpenId per request.

Important identity distinction

LARK_CLI_AS_USER should be the Feishu/Lark open_id, usually shaped like:

ou_...

It should not be:

oc_...   # chat_id / conversation id
user_id
union_id

For Feishu/Lark OAuth token lookup, the user identity should be the user's open_id.

Strict mode

LARK_CLI_REQUIRE_AS_USER=1 is important because silent fallback to Users[0] is dangerous in multi-user agent deployments.

If strict mode is enabled and no LARK_CLI_AS_USER is provided, lark-cli should fail with a clear error instead of using the default configured user.

Example error:

LARK_CLI_AS_USER is required

This prevents a false sense of correctness where a command succeeds but uses the wrong user's token.

Compatibility

This should be backward-compatible:

• If env vars are unset, existing behavior remains unchanged.
• Users[0] fallback continues to work unless LARK_CLI_REQUIRE_AS_USER=1 is explicitly set.
• Explicit --profile should still take precedence over env vars.

Use case

Hermes Agent receives a Feishu message from:

event.sender.sender_id.open_id = ou_xxx

Hermes then invokes lark-cli tools. The host agent wants to run lark-cli with:

LARK_CLI_PROFILE=default
LARK_CLI_AS_USER=ou_xxx
LARK_CLI_REQUIRE_AS_USER=1

This allows lark-cli to use the correct user-access-token for the actual message sender.

No files or tests are named. Start by tracing configuration profile selection and the user-access-token lookup entry points, then verify the specified precedence and strict-mode error behavior. Done means unset variables preserve current behavior, explicit profiles win, and request-scoped userOpenId values are used without falling back when strict mode is enabled.