…r across sidecar restart (#5448)

The in-process `_user_context_tokens[user_id]` cache populated by
inbound iLink callbacks vanishes on sidecar restart (any operator
upgrade, debug pass, or supervisor respawn). Without the
context_token, the bot's first reply after restart posts with an
empty token — iLink may reject it or post out-of-thread.

Fix: parse_wechat_msg also surfaces `context_token` via
`ChannelUser.librefang_user`, which the bridge round-trips bytewise
through serde (verified at crates/librefang-channels/src/sidecar.rs:766
inbound, :1204 outbound) so it survives serde + restart cleanly. The
in-memory cache stays as the freshness signal (the latest token Lark/
iLink issued is more current than whichever inbound the daemon happens
to round-trip back) and takes precedence in on_send.

Tests:
- New test_on_send_recovers_context_token_from_user_librefang_user_when_cache_cold
  simulates post-restart (cache empty, cmd.user.librefang_user carries
  the token) and asserts on_send recovers it.
- New test_on_send_ignores_url_shaped_librefang_user pins the cross-
  channel pollution guard (librefang_user is shared across channels —
  dingtalk puts a sessionWebhook URL there, telegram puts @username).
- cd sdk/python && pytest tests/test_wechat_adapter.py — 63 passed
  (was 61; +2 regression guards).

Surfaces from the #5439-followup audit chain (dingtalk #5423 →
qq #5431 → omnibus #5439 → THIS). Same library_user routing pattern,
distinct symptom — restart-survivability rather than cap-gate stripping.

… sidecar restart (#5449)

Same bug class as the wechat restart-fragility hotfix: the in-process
`_pending_req_ids[user_id]` cache vanishes on sidecar restart, so the
bot's first reply after restart degrades from `aibot_respond_msg`
(passive, free) to `aibot_send_msg` (active, quota-burning, blocked
for unlicensed bots and rate-limited hard for licensed ones).

Fix: parse_wecom_event also surfaces req_id via
`ChannelUser.librefang_user`. on_send's `_enqueue_text` learns a
`req_id_hint` keyword that falls back to it when the in-memory cache
is empty. Cache stays as the primary path because it holds the
FRESHEST req_id (subsequent inbounds clobber the dict but the
round-tripped librefang_user is whichever inbound the daemon happens
to surface — possibly stale).

Tests:
- test_on_send_recovers_req_id_from_user_librefang_user_when_cache_cold
  drives the post-restart shape (cache empty, librefang_user carries
  req_id), asserts on_send emits `aibot_respond_msg` with the
  recovered req_id rather than degrading to `aibot_send_msg`.
- test_on_send_in_memory_cache_wins_over_librefang_user pins the
  cache-first precedence (freshness invariant).
- test_on_send_ignores_url_shaped_librefang_user pins the cross-
  channel pollution guard.
- cd sdk/python && pytest tests/test_wecom_adapter.py — 65 passed
  (was 62; +3 regression guards).

Surfaces from the #5439-followup audit chain.

The reader() coroutine in librefang.sidecar.runtime swallows
exceptions from `adapter.on_command(cmd)` with a bare-except that
logged only `error=str(e)`. This silence let four consecutive
production reply-routing regressions ship with no warning sign:

- #5417 dingtalk (sessionWebhook cache key mismatch)
- #5431 qq (cmd.thread_id never set without `thread` cap)
- #5439 reddit (raised RuntimeError on every reply; vanished here)
- #5439 nextcloud/rocketchat/twitch/bluesky/mastodon (same class)

Each took at least one post-merge self-review pass to surface
because the original failure logged as `on_command failed
error="missing parent fullname"` with no clue about WHICH adapter
or WHICH line raised. Operators didn't notice because the bot
silently looked healthy — every adapter just stopped replying.

The fix is structural-but-conservative: keep the bare-except (we
cannot raise out of reader() without taking down the entire
sidecar process for one bad command) but add traceback +
error_type + cmd_type as structured fields so debuggers can grep
the offending adapter / line directly.

The richer long-term fix — surfacing on_command failures as a
structured JSON-RPC error response so the bridge correlates the
failure back to the original cmd id and the agent's
error-handling lane fires — needs a protocol change
(Response.error field) and is tracked in a follow-up issue.

No tests added: the change is purely log-content shape — it
doesn't alter exception handling behaviour, just adds context.
The protocol-level fix in the follow-up issue is what needs new
test coverage.

…e miss (closes #5452)

`parse_notification` stashed the AT Protocol `{root, parent}` reply
struct in an in-process `_thread_cache` LRU keyed by notification URI;
`_post_status` looked it up on outbound. After ANY sidecar restart
between the inbound mention and the bot's reply, the cache was empty,
the lookup returned None, and the reply posted as a top-level skeet
visible to every follower's feed instead of staying threaded.

The single-string `cmd.user.librefang_user` carrier added in #5439
only round-trips the URI. AT Protocol needs 4 fields (`root.uri`,
`root.cid`, `parent.uri`, `parent.cid`) which don't fit in one string,
so the #5439-style librefang_user fix doesn't structurally work here.

This commit (option-1 from the issue — bluesky-only, narrow blast
radius) adds:

* **`_recover_reply_ref`**: on `_thread_cache` miss in `_post_status`,
  issue one `app.bsky.feed.getPosts?uris=<uri>` XRPC call to re-fetch
  the post's cid + its existing `record.reply` chain, reconstruct
  `{root, parent}` using the same root-resolution rules
  `_compute_reply_ref` uses on inbound, re-populate `_thread_cache`
  for subsequent chunks. Recovery failure → WARN naming the URI +
  degrade to top-level skeet (same as pre-fix, but with operator
  visibility).

* **Transient-failure handling on the recovery path** so an extra
  failure mode doesn't permanently downgrade a recoverable reply:
    - **401**: invalidate `_access_jwt` and re-fetch a fresh token
      via `_get_token` (same pattern `_post_status`'s own 401 path
      uses at line ~487/693), retry the XRPC once.
    - **429**: honour `Retry-After` via the existing
      `_retry_after_secs` helper (same shape verify_credentials /
      poll / createRecord already use at lines 292/331/493), sleep,
      retry once.
  Without either retry, a session rotation OR a transient bsky rate
  limit on getPosts would silently downgrade every queued reply
  after a sidecar reboot to top-level skeet — even though the
  caller's subsequent createRecord refresh / retry would have saved
  them.

* **Sanity guard on the input URI**: must start with `at://`. A
  misrouted `librefang_user` from another channel (dingtalk
  sessionWebhook URL, telegram `@username`) returns None without
  any HTTP call, no cache write.

* **Defensive guards on the response shape**: missing `posts` key,
  empty list, non-dict entry, missing/empty `cid` — every malformed
  shape surfaces as None so the caller degrades cleanly rather
  than crashing on `.get()` against a non-dict.

* **WARN message broadened** to "post deletion, instance unreachable,
  rate limit, or auth issue" (was "post deletion / auth issue" —
  too narrow, missed the 5xx / 429 / network-blip cases).

* **`_LruCache` made thread-safe.** `_post_status` runs in
  `run_in_executor(None, ...)` which uses the default
  ThreadPoolExecutor — concurrent `put` / `get` from worker threads
  is real. Without a lock the `move_to_end + assignment + popitem`
  sequences race on OrderedDict's internal linked list. Added
  `threading.Lock` guarding `get`/`put`/`__len__`. The hammer-from-
  8-threads test pins this; remove the lock and the cap-violation
  assertion fires under stress.

The option-3 fix from #5452 (widen `SidecarSendParams` with a
`metadata: HashMap<String, Value>` bytewise-round-tripped field,
which would close the class for bluesky + wechat + wecom + any
future sidecar needing >1 field of correlation state) is a
separate protocol change spanning Rust + Python SDK + every
sidecar adapter — deliberately not in scope here.

Verification:
- `cd sdk/python && pytest tests/test_bluesky_adapter.py` — 53
  passed (was 44; +9 regression guards):
    * recovery happy-path: cache miss → getPosts → reply ref attached
      to createRecord body; cache re-populated.
    * deep-thread root preservation: post-with-reply's
      `record.reply.root` becomes the recovered root, not the
      immediate parent.
    * multi-chunk re-uses recovered ref: 3-chunk reply with cache
      miss = 1 session + 1 getPosts + 3 createRecord (5 calls
      total, not 7).
    * recovery failure → top-level skeet WARN.
    * cross-channel garbage rejected without any HTTP call.
    * 401 → invalidate session → _get_token re-creates → retry
      XRPC once with fresh bearer.
    * 429 → sleep `Retry-After` → retry once.
    * malformed responses (empty posts, non-dict entry, missing
      cid, no posts key) → None.
    * LruCache thread-safety: 8 threads × 200 puts + interleaved
      reads; cache cap respected, no exceptions raised.
- `cd sdk/python && pytest tests/` — full sidecar suite 1859
  passed (no regression in any of the other 26 adapters).
- Pre-existing `test_post_status_cold_cache_falls_back_to_unthreaded`
  renamed + updated to assert the getPosts re-fetch fires + 404s +
  then degrades.

…e miss (closes #5452) (#5471)

`parse_notification` stashed the AT Protocol `{root, parent}` reply
struct in an in-process `_thread_cache` LRU keyed by notification URI;
`_post_status` looked it up on outbound. After ANY sidecar restart
between the inbound mention and the bot's reply, the cache was empty,
the lookup returned None, and the reply posted as a top-level skeet
visible to every follower's feed instead of staying threaded.

The single-string `cmd.user.librefang_user` carrier added in #5439
only round-trips the URI. AT Protocol needs 4 fields (`root.uri`,
`root.cid`, `parent.uri`, `parent.cid`) which don't fit in one string,
so the #5439-style librefang_user fix doesn't structurally work here.

This commit (option-1 from the issue — bluesky-only, narrow blast
radius) adds:

* **`_recover_reply_ref`**: on `_thread_cache` miss in `_post_status`,
  issue one `app.bsky.feed.getPosts?uris=<uri>` XRPC call to re-fetch
  the post's cid + its existing `record.reply` chain, reconstruct
  `{root, parent}` using the same root-resolution rules
  `_compute_reply_ref` uses on inbound, re-populate `_thread_cache`
  for subsequent chunks. Recovery failure → WARN naming the URI +
  degrade to top-level skeet (same as pre-fix, but with operator
  visibility).

* **Transient-failure handling on the recovery path** so an extra
  failure mode doesn't permanently downgrade a recoverable reply:
    - **401**: invalidate `_access_jwt` and re-fetch a fresh token
      via `_get_token` (same pattern `_post_status`'s own 401 path
      uses at line ~487/693), retry the XRPC once.
    - **429**: honour `Retry-After` via the existing
      `_retry_after_secs` helper (same shape verify_credentials /
      poll / createRecord already use at lines 292/331/493), sleep,
      retry once.
  Without either retry, a session rotation OR a transient bsky rate
  limit on getPosts would silently downgrade every queued reply
  after a sidecar reboot to top-level skeet — even though the
  caller's subsequent createRecord refresh / retry would have saved
  them.

* **Sanity guard on the input URI**: must start with `at://`. A
  misrouted `librefang_user` from another channel (dingtalk
  sessionWebhook URL, telegram `@username`) returns None without
  any HTTP call, no cache write.

* **Defensive guards on the response shape**: missing `posts` key,
  empty list, non-dict entry, missing/empty `cid` — every malformed
  shape surfaces as None so the caller degrades cleanly rather
  than crashing on `.get()` against a non-dict.

* **WARN message broadened** to "post deletion, instance unreachable,
  rate limit, or auth issue" (was "post deletion / auth issue" —
  too narrow, missed the 5xx / 429 / network-blip cases).

* **`_LruCache` made thread-safe.** `_post_status` runs in
  `run_in_executor(None, ...)` which uses the default
  ThreadPoolExecutor — concurrent `put` / `get` from worker threads
  is real. Without a lock the `move_to_end + assignment + popitem`
  sequences race on OrderedDict's internal linked list. Added
  `threading.Lock` guarding `get`/`put`/`__len__`. The hammer-from-
  8-threads test pins this; remove the lock and the cap-violation
  assertion fires under stress.

The option-3 fix from #5452 (widen `SidecarSendParams` with a
`metadata: HashMap<String, Value>` bytewise-round-tripped field,
which would close the class for bluesky + wechat + wecom + any
future sidecar needing >1 field of correlation state) is a
separate protocol change spanning Rust + Python SDK + every
sidecar adapter — deliberately not in scope here.

Verification:
- `cd sdk/python && pytest tests/test_bluesky_adapter.py` — 53
  passed (was 44; +9 regression guards):
    * recovery happy-path: cache miss → getPosts → reply ref attached
      to createRecord body; cache re-populated.
    * deep-thread root preservation: post-with-reply's
      `record.reply.root` becomes the recovered root, not the
      immediate parent.
    * multi-chunk re-uses recovered ref: 3-chunk reply with cache
      miss = 1 session + 1 getPosts + 3 createRecord (5 calls
      total, not 7).
    * recovery failure → top-level skeet WARN.
    * cross-channel garbage rejected without any HTTP call.
    * 401 → invalidate session → _get_token re-creates → retry
      XRPC once with fresh bearer.
    * 429 → sleep `Retry-After` → retry once.
    * malformed responses (empty posts, non-dict entry, missing
      cid, no posts key) → None.
    * LruCache thread-safety: 8 threads × 200 puts + interleaved
      reads; cache cap respected, no exceptions raised.
- `cd sdk/python && pytest tests/` — full sidecar suite 1859
  passed (no regression in any of the other 26 adapters).
- Pre-existing `test_post_status_cold_cache_falls_back_to_unthreaded`
  renamed + updated to assert the getPosts re-fetch fires + 404s +
  then degrades.

…gs (#5450)

* fix(sdk): include traceback + cmd_type when on_command bare-except logs

The reader() coroutine in librefang.sidecar.runtime swallows
exceptions from `adapter.on_command(cmd)` with a bare-except that
logged only `error=str(e)`. This silence let four consecutive
production reply-routing regressions ship with no warning sign:

- #5417 dingtalk (sessionWebhook cache key mismatch)
- #5431 qq (cmd.thread_id never set without `thread` cap)
- #5439 reddit (raised RuntimeError on every reply; vanished here)
- #5439 nextcloud/rocketchat/twitch/bluesky/mastodon (same class)

Each took at least one post-merge self-review pass to surface
because the original failure logged as `on_command failed
error="missing parent fullname"` with no clue about WHICH adapter
or WHICH line raised. Operators didn't notice because the bot
silently looked healthy — every adapter just stopped replying.

The fix is structural-but-conservative: keep the bare-except (we
cannot raise out of reader() without taking down the entire
sidecar process for one bad command) but add traceback +
error_type + cmd_type as structured fields so debuggers can grep
the offending adapter / line directly.

The richer long-term fix — surfacing on_command failures as a
structured JSON-RPC error response so the bridge correlates the
failure back to the original cmd id and the agent's
error-handling lane fires — needs a protocol change
(Response.error field) and is tracked in a follow-up issue.

No tests added: the change is purely log-content shape — it
doesn't alter exception handling behaviour, just adds context.
The protocol-level fix in the follow-up issue is what needs new
test coverage.

* chore(codegen): auto-regenerate openapi.json + sdk + schema baselines [skip ci]

* chore(codegen): auto-regenerate openapi.json + sdk + schema baselines [skip ci]

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>