Make the restart-persistence e2e tolerate the atomic-rename swap window when reading API conversation history

[DaubnerF]

Problem

The restart-persistence e2e asserts on single, unguarded reads of a task's persisted API conversation history: api.hasTaskApiConversationHistorySequence at apps/vscode-e2e/src/suite/restart-persistence.test.ts:89, and again at restart-persistence.test.ts:109 after the task is resumed. Nothing polls.

Observed in version v3.82.1

Those reads race the writes that produce the file. History is persisted through safeWriteJson, which renames the existing target to a backup (src/utils/safeWriteJson.ts:130) and only then renames the new temp file into place (src/utils/safeWriteJson.ts:142); between the two renames the target path does not exist. The read path treats that miss as absent history rather than as a transient state: hasTaskApiConversationHistorySequence (src/extension/api.ts:256) receives an empty history from the task loader when the file is missing, and reports false when the read fails at all. A read that lands in that swap window therefore reports the turn sequence as missing even though the write is in flight and will land.

Consequence

A swap-window miss fails the restart assertion while the same read succeeds moments later: an intermittent e2e failure with no production bug behind it. Completion-time ordering needs no new test: src/core/task/__tests__/Task.persistence.spec.ts:509 already pins that the durable history write settles before completion is emitted, with siblings at Task.persistence.spec.ts:601 and Task.persistence.spec.ts:670 covering the retry paths. What is missing is test-side tolerance on the reads above.

Acceptance criteria

1. The restart-persistence e2e waits for the conversation history to become visible before asserting on it, through a bounded poll-until-visible with a deadline; no fixed sleeps.
2. The wait uses the same read that the assertions themselves use, so a swap-window miss can no longer surface as a false negative.