fix(loop-context): lock the daily-spend state file against concurrent writers

[KhaiTrang1995]

Problem

recordDailySpend() did an unguarded read-modify-write: read the JSON
state file, add tokensDelta, write it back, with no locking. Two
overlapping invocations for the same pattern -- e.g. two scheduled
loops hitting the same pattern around the same time -- both read the
same stale total and the second write clobbers the first, silently
losing a delta. This directly undermines the daily-budget circuit
breaker's purpose: a lost delta means loop-context can under-count
cumulative spend and delay or miss the escalation that's supposed to
cap cost.

Fix

loop-worktree already solved the same class of problem for its
manifest with a lock-file-plus-poll mutex (open with 'wx', treat an
existing lock older than 30s as stale and reclaim it, release in a
finally). Applied the same shape here, scoped per pattern's own lock
file so unrelated patterns never contend with each other.

Test plan

Added a regression test that fires two concurrent recordDailySpend
calls with the same delta and asserts both land (2000 total, not
1000). Full clean rebuild + npm test: 52/52 passing.

[cobusgreyling]

Needed lock around the daily-spend read-modify-write. Same wx + stale-reclaim shape as loop-worktree. Concurrent test asserting 2000 not 1000 is the right regression.