fix(e2e): retry lock verification read to handle auto_init race

[ralphbean]

Summary

• GitHub's auto_init creates a default README.md asynchronously when a repo is created
• Our CreateOrUpdateFile overwrites it, but the verification read can briefly return the stale auto-init content (# e2e-lock) instead of our run ID
• This caused tryCreateLock to think it lost the lock race when it had actually won
• Now retries the verification read up to 5 times with linear backoff, logging each mismatch

Depends on #1612 — based on fix/e2e-lock-debug.

Test plan

• go test -tags e2e ./e2e/admin/ -run TestAcquire passes
• make go-test passes
• make lint passes

🤖 Generated with Claude Code

[github-actions]

Site preview

Preview: https://1f3a1d03-site.fullsend-ai.workers.dev

Commit: 29b66f675bf8d4b011af3660a08db595e82e4534

[fullsend-ai-review]

Review

Findings

No findings.

The retry loop correctly handles the auto_init race condition with proper context cancellation support, linear backoff (2–5s waits), and clear diagnostic logging at each attempt. The for i := range 5 syntax is fine for Go 1.22+. The extra GetFileContent call after the loop is necessary since content is scoped inside the loop body, and discarding the error is acceptable for a log-only read in e2e test infrastructure.

Previous run

Review

Findings

No findings.

The retry loop correctly handles the auto_init race condition with proper context cancellation support, linear backoff (2–5s waits), and clear diagnostic logging at each attempt. The for i := range 5 syntax is fine for Go 1.22+. The extra GetFileContent call after the loop is necessary since content is scoped inside the loop body, and discarding the error is acceptable for a log-only read in e2e test infrastructure.

Previous run

Review

Findings

No findings.

The retry loop correctly handles the auto_init race condition with proper context cancellation support, linear backoff (2–5s waits), and clear diagnostic logging at each attempt. The for i := range 5 syntax is fine for Go 1.26. The extra GetFileContent call after the loop is necessary since content is scoped inside the loop body, and discarding the error is acceptable for a log-only read in e2e test infrastructure.

Previous run

Review

Findings

No findings.

The retry loop correctly handles the auto_init race condition with proper context cancellation support, linear backoff (2–5s waits), and clear diagnostic logging at each attempt. The for i := range 5 syntax is fine for Go 1.22+. The extra GetFileContent call after the loop is necessary since content is scoped inside the loop body, and discarding the error is acceptable for a log-only read in e2e test infrastructure.

Previous run (2)

Review

Findings

No findings.

The retry loop correctly handles the auto_init race condition with proper context cancellation support, linear backoff (2–5s waits), and clear diagnostic logging at each attempt. The for i := range 5 syntax is fine for Go 1.26. The extra GetFileContent call after the loop is necessary since content is scoped inside the loop body, and discarding the error is acceptable for a log-only read in e2e test infrastructure.