Problem

The Test / Ubuntu (shard 1/4) lane flaked on librefang-api::goals_routes_integration::goal_run_start_then_stop_with_agent (surfaced on the unrelated Dependabot PR #6080, which touches only dashboard npm deps):

assertion `left == right` failed   (goals_routes_integration.rs:570)
  left: Some(false)    // actual run["running"]
 right: Some(true)

Root cause

GoalRunner::state() (goal_runner.rs) snapshots a run with a non-blocking try_lock() so an async HTTP handler never parks on a tick.
GET /api/goals/{id}/run renders a None snapshot as {"running": false} — which is indistinguishable from "no run exists".

The run loop, however, held that same state mutex across persist_run() — a synchronous SQLite write (save_run), including a potentially-blocking connection-pool checkout:

{
    let mut s = state.lock().await;
    s.iteration = iteration + 1;
    ...
    persist_run(&store, &s);   // blocking I/O while holding the lock
}

Under load (CI runs ~1800 tests in parallel) a GET /run landing inside that write window loses the try_lock and reports a live run as not running.
This is also a real product issue: a dashboard polling /run would intermittently flicker "stopped" for an active goal run.

Confirmed by code, not guesswork: save_run is synchronous rusqlite (crates/librefang-memory/src/goal_run_store.rs), and state() uses try_lock (crates/librefang-kernel/src/goal_runner.rs).
The race is one short persist window per run, so it only surfaces under heavy parallelism — 150 isolated local iterations did not reproduce it.

Fix

Update the in-memory state under the lock, release it, then persist the cloned snapshot outside the lock — in both the success and the error tick paths.
state is written only by the single loop task, so the cloned snapshot stays consistent after the lock is released.
This shrinks the lock hold from "across a blocking SQLite write" to "a few synchronous field writes" (sub-microsecond), so the try_lock no longer realistically contends.

Also clarified the state() doc comment to make the lock-discipline invariant explicit, so a future edit does not reintroduce a lock-across-I/O hold.

Verification (Linux dev container)

• cargo test -p librefang-kernel --lib goal_runner — 12 passed, 0 failed
• cargo test -p librefang-api --test goals_routes_integration — 26 passed, 0 failed
• cargo clippy -p librefang-kernel --lib -- -D warnings — clean
• cargo fmt -p librefang-kernel --check — clean

Scope

The existing goal_run_start_then_stop_with_agent integration test is the regression guard — it exercises start → GET /run → assert running:true and was the test that flaked.
A bespoke unit test for this sub-millisecond race would itself be timing-dependent (probabilistic), which the repo's no-flaky-tests policy rules out; the fix is verified at the code level and by the now-stable integration test.

This is a kernel-internal fix, intentionally not bundled into Dependabot PR #6080 (npm-only) per the one-PR-one-concern rule.