PullRepo update stays InProgress for seconds after its end_ts, because the Update write is gated on RefreshRepoCache

What happened

Expected: once a PullRepo update's end_ts is set, a caller polling ListUpdates sees that update as Complete.

Actual: the update keeps being reported as InProgress for 1 to 6+ seconds after its own end_ts value. The timestamp itself is correct; the record only becomes visible later.

Reading the completion path in bin/core/src/api/execute/repo.rs, Core calls update.finalize() (which sets end_ts and status = Complete in memory) right after Periphery's response, then awaits RefreshRepoCache (bin/core/src/api/write/repo.rs), and only after that awaits the write of the Update document. RefreshRepoCache runs its own git::pull_or_clone into Core's separate /repo-cache/<provider>/<repo>/<branch>/latest checkout, to populate Repo.info.latest_hash and latest_message. The Update write is therefore gated on a second, independent git operation against the same remote.

This matters for anything that polls update status to decide when to advance. In our case a Komodo procedure of sequential executions waits on ListUpdates between stages, and this lag sits inside every gap between two stages.

Related: #1258 reports a correctness failure (latest_hash stuck null) in this same RefreshRepoCache path. Different symptom, same second-clone design.

Steps to reproduce

1. Configure a Repo resource against a remote git host (GitHub in our case) and a Periphery agent that holds the working copy.
2. Run PullRepo on that Repo, or run a procedure that executes it.
3. While it runs, poll ListUpdates for that update and record the status against wall-clock time.
4. After it finishes, read the same update and compare its end_ts to the moment the poll first reported anything other than InProgress.

Logs / error output

Observed on our host across the pulls of a single procedure run: the interval between an update's end_ts and the first poll that no longer reports InProgress was roughly 6.1 s in one gap of the run and roughly 1.4 s three intervals later in the same run, so it is variable rather than a fixed delay.

MongoDB is not the bottleneck. On the live Update collection (11531 documents), explain("executionStats") on both the ListUpdates query shape and the per-repo lookup query shape reports executionTimeMillis: 0 with an IXSCAN, not a collection scan. Standalone single node, default write concern.

Environment

• Komodo Core version (GetVersion): 2.3.3
• Komodo Periphery version: 2.3.3
• Install method: Docker (ghcr.io/moghtech/komodo-core:2)
• OS / arch: Linux 6.18.38-Unraid x86_64
• MongoDB version: 8.3.9 (standalone, no replica set)
• Repo remote: github.com over HTTPS