session pull stops on an _index.json conflict when two machines push the same repo #1133

Two machines that push sessions for the same repo both append to that repo's _index.json. The second push is rejected, and teamai session pull then hits a merge conflict in _index.json that it cannot resolve.

What happens

1. Machine A and machine B each run teamai session push. Both append an entry to the same sessions array in _index.json and commit locally.
2. A pushes first. B's push is rejected as non-fast-forward. pushToRemote keeps the local commit and prints ✗ Remote push failed (local commit kept).
3. On B, teamai session pull runs git pull. Both sides appended at the same spot, so git cannot merge _index.json. runGitStep prints Check that <repo> is a git repository with a configured remote, then retry. and exits 1. That advice is wrong for this case.
4. The team repo checkout is left mid-merge with conflict markers in _index.json. A second session pull fails too, because git refuses to pull with unmerged files.

I checked steps 2 to 4 with plain git: a bare remote, two clones, and the same pretty-printed append to _index.json (Automatic merge failed, UU _index.json). The messages in steps 2 and 3 come from pushToRemote and runGitStep in src/session-flow/session-cmd.ts. I did not run two real teamai installs against one hub, and I did not check what the next session push does while the merge is still in progress.

Why it can be fixed without user action

_index.json is derived data. SyncManager.rebuildIndex rebuilds it from the session files, and readIndexForWrite already rebuilds it when it finds conflict markers. The session files themselves have unique names, so they do not conflict.

Proposal

When git pull in session pull stops on conflicts only in _index.json files, take either side, rebuild those indexes from the session files, and finish the merge. Any other conflict stops with an error that names the conflicted files and says to resolve them in the team repo checkout.

#1135 adds a file lock around _index.json writes, which fixes concurrent pushes on one machine. It does not fix this case, because here the two writers are on different machines.