Failed to reset Git HEAD state leading to disappearing file

[masterzen]

Description

While working today I had several instance of the following happening:

% jj edit kslppmnszrws
Error: Failed to reset Git HEAD state
Caused by:
1: Could not acquire lock for index file
2: The lock for resource '<redacted>/.git/index' could not be obtained immediately after 1 attempt(s). The lockfile at '<redacted>/.git/index.lock' might need manual deletion.
% jj edit kslppmnszrws
Reset the working copy parent to the new Git HEAD.
Working copy  (@) now at: kslppmnszrws cee281f25af8 bundle stuff
Parent commit (@-)      : kwompulrssln 8a6c7b108e98 masterzen/my-branch* | Refactor interface
Added 0 files, modified 3 files, removed 0 files

I understand that something is trying to modify the index while jj is working and this is not safe (BTW this is a colocated repo).
The problem is that I don't see how I can find what's doing this, I've disabled my git prompt (starship), not running VScode in that repo. The only thing that could be the cause is Goland, but I've been using it for a week without issue. Note that I run with watchman in automated snapshot mode.

Still, the problem is that it created a situation that I wasn't really able to recover from: somehow in an earlier change I had a file missing (probably a previous instance of the index lock issue). Looking at jj log -s, I can see the file being added at an earlier change, and never removed in any of the subsequent changes.
But no matter what I did, jj edit of any intermediate nor the change where that file was added made the file appear on the filesystem!
I finally recreated from the diff output of jj show and was able to get the file back in all the changes.

I understand you can't easily fix such kind of issue, but I was wondering:

1. Is there a way the op log could have helped me understand the issue or fix it correctly (something like force replaying all the diffs as they were correct)
2. I was wondering if it was possible to "uncolocate" the repo? (I have work in progress, so I'd prefer not to jj git clone again)

[masterzen]

I think the issue was with the git background maintenance which was activated for this repository. I've since deactivated it and never got the issue again.
Closing.