Re-do of dependabot's #3989 on top of latest main: the original PR
conflicted on pnpm-lock.yaml after #3989-#3995's other dashboard dep
bumps merged. Regenerated lockfile via pnpm install.

…3378 part 1 fixup)

Addresses review feedback on PR #4544.

* Extract remove_agent_inner / vacuum_inner free fns. The sync method
  takes its own conn lock and forwards; the async wrapper takes the
  lock inside spawn_blocking and forwards. One transaction body, one
  truth — a future change to the agent-deletion strategy or the VACUUM
  flow (e.g. adding a new per-agent table) only has to land in one
  place. Substrate.rs:203-205 already warned about exactly this kind
  of cross-place coupling.

* Rewrite async_wrappers_do_not_park_current_thread_runtime to assert
  on ordering instead of a 25 ms wall-clock threshold. The blocker
  thread captures released_at the instant the lock guard drops; a
  tokio task captures tick_at after a 20 ms sleep. The test asserts
  tick_at < released_at — true in the correct (offloaded) case
  because the tick fires during the 100 ms hold; false in the broken
  case because the runtime is parked until the lock releases, so
  released_at lands first. No timing budget — the test stays
  decisive under heavy CI jitter (Windows / llvm-cov instrumentation
  has been observed to add 30-80 ms per scheduler hop on this repo,
  see #3989 series).

* Add tracking comments to the three async wrappers that don't yet
  have an in-tree caller (structured_get_async,
  get_agent_session_ids_async, delete_canonical_session_async).
  Staged for #3378 part 2 — the comment marks them so a future
  dead-code sweep doesn't remove them before the kernel-side
  migration lands.

…#4544)

* fix(memory): async wrappers for kernel substrate calls (#3378 part 1)

The hottest async kernel paths today take `std::sync::Mutex<Connection>`
synchronously on the tokio worker thread. Per #3378, when one holder
runs a slow `INSERT` (FTS5 tokenization, transactional cascades), the
worker stalls and every unrelated future scheduled on it is delayed
until the lock is released. Only `save_session_async` and the embedding
helpers used `spawn_blocking`; the rest of the surface did not.

This change wires every substrate method that is reached from an async
fn through `tokio::task::spawn_blocking`, so the connection mutex is
always acquired on the blocking pool, never on a runtime worker:

- `save_agent_async`
- `load_all_agents_async`
- `remove_agent_async`
- `structured_get_async`
- `get_session_async`
- `get_agent_session_ids_async`
- `delete_canonical_session_async`
- `append_canonical_async`
- `vacuum_if_shrank_async`

The original sync methods are kept verbatim. Tests, migrations, and
the (still-sync) `KernelHandle` trait methods that aren't on a hot
async path use them unchanged, so no caller's signature shifts.

Inside `crates/librefang-kernel/src/kernel/mod.rs` the seven async-fn
call sites that took the connection mutex on a runtime worker are
migrated to the new `_async` siblings:

- `execute_llm_agent` — `save_agent`, `append_canonical`
- `start_background_agents` — `load_all_agents`, `remove_agent`,
  `vacuum_if_shrank`
- `replace_tool_result_in_session` — `get_session` (×2)

These are the high-frequency paths: every LLM turn fires
`execute_llm_agent`, every reboot fires `start_background_agents`,
and every approval / replay fires `replace_tool_result_in_session`.

A regression test in `substrate.rs` (`async_wrappers_do_not_park_
current_thread_runtime`) holds the connection mutex from a non-tokio
OS thread for ~30 ms, then drives `save_agent_async` on a single-
threaded tokio runtime concurrently with a 5 ms `tokio::time::sleep`.
If the wrapper had taken the mutex on the runtime worker (the pre-fix
pattern) the sleep would block for the full hold time; the test
asserts it returns within 25 ms.

This is a partial fix for #3378. Three other surfaces are still
synchronous and called from async paths and need follow-up:

1. ~21 sync kernel methods called from axum handlers (`kill_agent`,
   `reset_session`, `set_agent_model`, etc.). These need their
   `KernelHandle` trait counterparts converted to async, or each
   axum call site wrapped in `spawn_blocking`. Bigger surface,
   warrants its own PR.

2. `MeteringEngine` (`librefang-kernel-metering`) — `record`,
   `check_all_and_record`, `check_user_budget`,
   `check_global_budget` are sync and called from
   `send_message_full_with_upstream` and `execute_llm_agent`.

3. `AuditLog` (`librefang-runtime/src/audit.rs`) — `record` /
   `record_with_context` are sync, called from the same async
   hot paths as #2.

Refs #3378.

* refactor(memory): share inner fns + ordering-based regression test (#3378 part 1 fixup)

Addresses review feedback on PR #4544.

* Extract remove_agent_inner / vacuum_inner free fns. The sync method
  takes its own conn lock and forwards; the async wrapper takes the
  lock inside spawn_blocking and forwards. One transaction body, one
  truth — a future change to the agent-deletion strategy or the VACUUM
  flow (e.g. adding a new per-agent table) only has to land in one
  place. Substrate.rs:203-205 already warned about exactly this kind
  of cross-place coupling.

* Rewrite async_wrappers_do_not_park_current_thread_runtime to assert
  on ordering instead of a 25 ms wall-clock threshold. The blocker
  thread captures released_at the instant the lock guard drops; a
  tokio task captures tick_at after a 20 ms sleep. The test asserts
  tick_at < released_at — true in the correct (offloaded) case
  because the tick fires during the 100 ms hold; false in the broken
  case because the runtime is parked until the lock releases, so
  released_at lands first. No timing budget — the test stays
  decisive under heavy CI jitter (Windows / llvm-cov instrumentation
  has been observed to add 30-80 ms per scheduler hop on this repo,
  see #3989 series).

* Add tracking comments to the three async wrappers that don't yet
  have an in-tree caller (structured_get_async,
  get_agent_session_ids_async, delete_canonical_session_async).
  Staged for #3378 part 2 — the comment marks them so a future
  dead-code sweep doesn't remove them before the kernel-side
  migration lands.