P0 #1: Conflict detection now happens BEFORE push to prevent data loss.
Previously: Pull -> Push -> Detect conflicts (wrong - conflicts overwritten)
Now: Pull -> Detect conflicts -> Push (skip conflicting issues)

P0 #2: Added SyncContext struct for thread-safe sync operations.
- SyncContext holds store, actor, dbPath, issueIDCounter
- WithContext variants of all sync functions
- globalContextIDCounter for cross-context uniqueness
- Enables concurrent sync operations without race conditions

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Executed-By: beads/crew/emma
Rig: beads
Role: crew

Add flock-based shared/exclusive locking for JSONL reads (auto-import)
and writes (export/flush) to prevent corruption when sync and daemon
flush race.

**No new dependencies** - uses existing gofrs/flock v0.13.0 (already in go.mod)

Security fixes from SECURITY_AUDIT.md:
- Issue #1: Sync export and daemon auto-flush race causing data loss
- Issue #3: Auto-import reading partially-written JSONL during export

Changes:
- Add jsonl_lock.go with JSONLLock type using gofrs/flock
- Update exportToJSONLDeferred to acquire exclusive lock during export
- Update autoImportIfNewer to acquire shared lock during import
- Add comprehensive race condition tests
- Add generateUniqueTestID helper for test isolation

The JSONL lock ensures that:
- Export operations have exclusive access (no concurrent reads/writes)
- Import operations share access with other readers, block during writes
- Lock is held for entire export+commit+finalize sequence

Co-Authored-By: SageOx <ox@sageox.ai>

…townhall#1706)

* perf(doctor): fix O(n) full-table scans causing 130s doctor runs

Three performance fixes for bd doctor on large databases (23k+ issues):

1. CheckDuplicateIssues (66s → 10ms): Replace SearchIssues() that loaded
   ALL issues into memory with SQL GROUP BY aggregation. The old code
   transferred 23k full issue rows (50+ columns) over MySQL wire protocol
   just to count duplicates.

2. CheckStaleClosedIssues (57s → 4ms): Replace SearchIssues() that loaded
   ALL closed issues with SELECT COUNT(*) SQL query. Same root cause as #1.

3. ResolvePartialID (60s+ → <1s for missing IDs): The substring search
   fallback loaded ALL issues when exact match failed. Now passes the hash
   as a search query to leverage SQL-level id LIKE filtering instead of
   transferring the entire database to Go for in-memory matching.

Total bd doctor runtime: 130s → 6s (22x speedup).
Total gt doctor runtime: infinite hang → 15s.

Root cause: These checks used store.SearchIssues() which does SELECT id
then GetIssuesByIDs() (full row fetch). On Dolt server mode with 23k+
issues, transferring all rows over MySQL wire protocol is catastrophically
slow. SQL aggregation and filtering avoid the data transfer entirely.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* test(doctor): add 7 missing tests for performance PR

CheckStaleClosedIssues (6 tests):
- DisabledSmallCount: threshold=0, <10k closed → OK
- DisabledLargeCount: threshold=0, ≥10k closed → warning
- EnabledWithCleanable: threshold=30d, old issues → correct count
- EnabledNoneCleanable: threshold=30d, recent issues → OK
- PinnedExcluded: all pinned → 0 cleanable
- MixedPinnedAndStale: 5 stale + 3 pinned → reports 5

CheckDuplicateIssues (2 tests):
- MultipleDuplicateGroups: 2+ groups → correct groupCount/dupCount
- ZeroDuplicatesNullHandling: SUM() NULL → defaults to 0

ResolvePartialID (1 test):
- TitleFalsePositive: hash in title but different ID → rejected

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>