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