Map tsuijinglei@gmail.com → hiddenpuppy.

…t exhaustion for fallback

Fixes NousResearch#13887

OpenRouter returns HTTP 403 (not 402) for key-limit and spend-limit
errors.  The existing _is_payment_error() only checked 402/429/None,
so these 403s were not classified as payment exhaustion and auxiliary
calls would fail immediately instead of falling back to the next provider.

Now _is_payment_error() also checks status == 403 and looks for
OpenRouter-specific keywords: key limit, spending limit, spend limit,
total limit, credit limit, quota exceeded.

This keeps the fix scoped: only 403s with these specific phrases are
treated as payment errors.  Other 403s (auth, forbidden, etc.) still
raise normally.

The fallback path already skips the failed provider via
_try_payment_fallback(), so no changes are needed there.

Map jerome@clawwork.ai → HiddenPuppy.

…H/tunnels

Fixes NousResearch#13870

prompt_toolkit sends \x1b[6n (Device Status Report) to query cursor
position; the terminal replies with \x1b[row;colR. Over SSH/cloudflared
tunnels these CPR responses leak as raw text (e.g. 20

…sections

Fixes NousResearch#13396

PUT /api/config was calling save_config() with only the payload from the
client, which replaced the entire ~/.hermes/config.yaml file. If a dashboard
UI sent only the sections it manages (agent, display), everything else
(model, custom_providers, compression, auxiliary, fallback_model, etc.) was
silently deleted.

Now update_config() loads the existing config, deep-merges the incoming
payload into it, and saves the merged result. Keys present in the payload
overwrite existing values; keys absent from the payload are preserved.

This matches the behavior third-party clients already assume and prevents
accidental data loss.

… callback failure

Fixes NousResearch#13924

When a user clicks an approval button on a Feishu interactive card, the
synchronous callback response (P2CardActionTriggerResponse with CallBackCard)
sometimes fails with error 220340, leaving the card unchanged and the user
confused about whether the action worked.

Root cause: Feishu's card-action callback response path is unreliable over
some transports. The card update in the callback response may be rejected
while the approval resolution (scheduled asynchronously) succeeds.

Fix: In _resolve_approval(), proactively call im.v1.message.update with the
resolved card BEFORE calling resolve_gateway_approval(). This uses the stored
message_id from _approval_state, so it doesn't depend on the callback response
path at all.

- Card is updated even if approval resolution fails
- If the API update also fails, we log a warning but still resolve the
  approval so the agent isn't blocked
- The callback response is still returned for clients where it works