fix: run profile learning from any active instance under a cross-process lock

[doublepi123]

What

Profile learning currently only runs on the instance that owns the shared web server, so the queue stalls whenever that owner stops seeing sessions and is disabled entirely when the web server is off. Any active instance may now learn: performUserProfileLearning takes a cross-process lock before selecting prompts.

Cross-process lock (rewritten from the original FS lock)

• Ownership lives in a standalone SQLite coordination DB (.profile-learning-coordination.db under the storage path), deliberately separate from the memory database — ordinary memory writes proceed while the lock is held
• Acquisition is a single INSERT ... ON CONFLICT DO NOTHING; the winner is decided by rows-affected, and a CAS token guards every takeover
• No TTL takeover: a conflicting row is only replaced via conditional UPDATE ... WHERE owner_token = <old> when the recorded owner is provably dead (pid + boot_id + starttime identity; non-empty starttime verified in tests). A live owner can never be preempted while deployed
• Release is DELETE ... WHERE owner_token = <token>, so a stale release from a previous owner (even with a reused PID) can never drop someone else's lock
• Fail-closed: if the coordination state cannot be trusted, the round is skipped rather than run concurrently

Service wiring

• The in-process guard is set before the first await so same-process re-entry bounces instead of queueing; release happens in a nested finally so the flag stays raised while the release await is in flight, and still resets when release itself rejects

Cold-buffer hardening

• Cold buffer is read as bytes with a zero-length guard; short writes are detected (write stalled), never silently truncated into multi-byte corruption
• Fail-closed schema handling: blank or unexpected-schema files refuse to overwrite instead of being treated as empty

Storage errors propagate (no provider fallback masking)

• Profile parse/merge failures stay outside the provider fallback catch, so native storage errors propagate instead of being retried through the LLM path

Tests

• Lock coordination (14), real two-process service lock (8) — including a case proving ordinary memoryClient.addMemory/search/list complete while the learning lock is held, cold-buffer cross-process (16), storage-error no-fallback (4)
• Combined fork deployment QA: 542 pass / 0 fail / 4 skip

Fixes the stalled-queue and disabled-learning failure modes for multi-instance deployments.

[karaaslanz]

I traced the new lock's stale-reclaim path because the PR's correctness depends on mutual exclusion across the full LLM/write flow.
One issue looks worth fixing before relying on it: readLiveLock() reclaims any lock older than 30 minutes even when isProcessAlive(state.pid) is true. The test reclaims a lock held past the staleness deadline actually locks this behavior in by writing the live parent test PID and expecting the child to steal it after 31 minutes.
That means a genuinely live profile-learning run that exceeds the TTL loses mutual exclusion and a second process can analyze/write the same batch — exactly the race this PR is meant to prevent.
The comment says the TTL is for the dead-holder/PID-reuse case, but age alone cannot distinguish a reused PID from the original live holder. I'd keep a confirmed-live holder authoritative, or add a stronger owner identity/heartbeat before allowing stale reclamation, then add a regression that an old-but-still-live holder is not stolen.