…nnelUser.librefang_user across mastodon, nextcloud, reddit, twitch, bluesky, rocketchat (#5439)

Same root cause as the dingtalk (#5423) and qq (#5431) fixes. All six
sidecars read cmd.thread_id in on_send to recover a per-message
correlation key (mastodon: status_id; nextcloud: msg id; reddit:
parent fullname; twitch: tag-id; bluesky: at-URI; rocketchat: tmid).
But the daemon's bridge only sets cmd.thread_id when BOTH:

  * the channel config has [channels.X.overrides] threading = true
    (defaults to false; verified at
    crates/librefang-channels/src/bridge.rs:2968-2973), AND
  * the sidecar declares the "thread" capability (verified at
    crates/librefang-channels/src/sidecar.rs:1372-1395 — without it,
    send_in_thread degrades to plain send which hardcodes
    thread_id: None at line 1203).

All six declare `capabilities: list = []`. Production operators with
default `threading = false` (and even with threading=true, because
the cap-gate fails first) get cmd.thread_id = None on every reply.

Net effect, by severity (ranked by user-visible damage):

  HIGH: reddit — every reply RAISED RuntimeError("missing parent
        fullname"); RuntimeError caught by SDK's bare-except
        on_command wrapper and logged to stderr only. Operator
        saw no message land. Bot looked healthy.

  MED:  nextcloud / rocketchat — bot's "thread reply" posted at
        channel root with no link back to the trigger. The
        docstrings of both modules explicitly advertise this as
        their headline improvement over Rust parity; the modules
        in fact shipped the same bug.

  MED:  bluesky — reply intent became top-level skeet, no thread
        context. Visible to all followers' feeds (not just the
        thread participants).

  LOW:  mastodon — reply degraded to top-level toot; message
        still landed but UI lost the in-reply-to context.
        Bonus pre-existing semantic bug ALSO fixed: parse
        surfaced status.in_reply_to_id (the PARENT the mention
        was responding to) as the reply target instead of
        status.id (the mention itself); the bot would have
        replied to the wrong account even if the round-trip
        worked.

  LOW:  twitch — chat UI lost the @reply-parent-msg-id badge;
        plain PRIVMSG still delivered the text.

The bugs were not caught by the test suites because every on_send
test fabricated cmd.thread_id="..." on a stub — the realistic
daemon shape (thread_id=None, user.librefang_user=<id>) was
uncovered.

Fix (uniform across all six):
- parse_X_event: also stash the correlation key in
  ChannelUser.librefang_user (which the bridge round-trips bytewise
  through serde regardless of capabilities/overrides — verified at
  sidecar.rs:766 inbound, :1204 outbound). Keep the existing
  thread_id assignment for the forward-compat threading=true path.
- on_send: read cmd.user["librefang_user"] FIRST, fall back to
  cmd.thread_id. Sanity guard — reject URL-shaped or whitespace-
  bearing values (librefang_user is shared across channels; dingtalk
  puts a sessionWebhook URL there, telegram puts an @username — we
  must not POST replies with cross-channel garbage as the
  correlation key).
- Reddit gets the strongest guard: enforce t{1,3,4,5}_ prefix.
- Bluesky gets the strongest guard: enforce at:// prefix.

Tests (per adapter — at minimum one regression guard each):
- test_on_send_recovers_X_from_user_librefang_user drives the
  realistic daemon shape and asserts the outbound payload contains
  the correlation key. Each fails on the pre-fix code.
- reddit gets a second test pinning the prefix-guard
  (rejects URL-shaped librefang_user, falls back to thread_id).
- mastodon parse-test rewritten — the pre-fix test pinned the
  buggy behaviour (asserted thread_id == in_reply_to_id which was
  the wrong target).

Verification: cd sdk/python && pytest tests/test_{mastodon,nextcloud,
reddit,twitch,bluesky,rocketchat}_adapter.py — 343 passed (was 336;
+7 regression guards across 6 adapters, -1 pre-fix wrong-behaviour
assertion deleted via rewrite).

Pre-existing structural issue NOT fixed here (out of scope):
- SDK runtime.py:245-247 has a bare-except on on_command that
  swallowed Reddit's RuntimeError silently. The immediate fix here
  is to not raise in the first place (no production path now
  reaches the missing-parent branch), but the bare-except itself
  is a footgun — future raises from on_send will also vanish
  to stderr only. Worth a follow-up: re-raise after logging so
  the bridge can record the failure and trigger the agent's
  error-handling path.

Same investigation pattern: dingtalk #5423 first surfaced this
bug class via post-PR self-review; qq #5431 confirmed it
generalised; this PR closes out the remaining six known cases.

…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.

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.

…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>