Concurrent local-store initialization can fail valid inspectors #90

Parallel database inspection workers open independent handles to one baseline store. Each can observe missing fingerprint metadata and race to insert the same primary key; otherwise valid opens fail with UNIQUE constraint failed: meta.key, reducing local baseline coverage. Concurrent consumers can also deliver the intended one-time upgrade notice more than once.

Reproduced against upstream 9e41414abed05f10ad7ff2fbe7662a5172f151f7 with sixteen concurrent real store.Open calls, both on a new database and a legacy database containing a snapshot. Three baseline repetitions produced duplicate-key errors. A separate sixteen-handle notice-consumption test delivered the same notice two to four times.

I would like to handle this because parallel read-only inspections should not race during local metadata initialization. Serialize in-process initialization, let only the winning metadata insertion create the legacy notice, and consume that notice with a single SQLite statement. Normal data operations remain outside the mutex; old snapshots stay intact.

The expanded regression passes twenty race-enabled repetitions, including preserved legacy snapshots, fresh-store no-notice behavior and exactly-once notice consumption. Full store/CLI race tests, committed-HEAD gate, all six release-target builds and full race suite pass.

Boundary: the mutex serializes initial opens across paths within one process; it does not claim to eliminate every cross-process SQLite schema-lock contention case. No schema migration, data deletion, retention change or dependency change is introduced.