Semantic vector publication deterministically fails at first commit batch with store_concurrent_mutation

[HashemKhalifa]

Observed

On PR #707 current head 53b7999, shipping as 0.1.0-beta.37+53b7999fb92fa98cb23f10508d94932e022264eb.dirty, semantic indexing for an existing registered project fails deterministically at the first committed batch.

The model artifact is installed and verified. Runtime initially reports indexing with 168,391 total units, advances to 289 completed units, then transitions to:

• lifecycle state: failed
• detail: semantic runtime publication commit_batch failed: store_concurrent_mutation
• retryable: true
• runtime state: degraded
• runtime reason: runtime_failure
• active generation: null

A supported daemon restart repeats the same 0 -> 289 -> failed transition. The reproduction occurred after the earlier disk-full condition had been cleared; no new disk-full event accompanied this failure.

Related graph state

The latest #765 recovery stack improves the code-index side: the daemon serves an observed stale generation with 63,695 symbols and 82,738 edges while the replacement generation refreshes. However, semantic-vector publication still conflicts independently, so the #765 same-store/reseat fixes do not cover this commit_batch path.

Expected

A retryable concurrent mutation during semantic batch publication should be serialized or retried from the durable checkpoint, allowing vector indexing to progress beyond the first batch. Runtime and lifecycle should expose the same terminal state if retries are exhausted.

Actual

The first conflict immediately terminates semantic indexing. Restarting repeats the same failure, leaving calibration and strict semantic retrieval unavailable.

Reproduction outline

1. Run the daemon from PR feat: consolidate TraceDecay V2 PR8-PR13 delivery #707 head 53b7999.
2. Open a registered project whose code generation contains 168,391 semantic units.
3. Ensure JinaEmbeddingsV2BaseCode is installed with auto-download enabled.
4. Observe semantic runtime move from installed to indexing.
5. At 289 completed units, observe commit_batch/store_concurrent_mutation and degraded/runtime_failure.
6. Restart the daemon and observe the same transition again.

Related: #765, but this report is specifically the semantic vector generation commit_batch path rather than code graph activation/seating.

[HashemKhalifa]

Additional live reproduction evidence on beta.37 with PR #707 commit 159989b:

• The code generation is complete/current and the graph is ready before the terminal semantic result.
• The semantic lifecycle enters indexing, then fails at begin_generation with store_concurrent_mutation.
• Retrying only the typed ConcurrentMutation 12 times with capped exponential backoff (25 ms to 1 s; about 7.6 s total) still reaches the same failure.
• This makes short-lived lock contention unlikely; the conflict appears persistent/logical. No pull request is being proposed from that unsuccessful workaround.

PR #707 has since advanced to 2f148f0, but the intervening commits are session/runtime performance changes rather than a semantic publication fix.