Retry APIM pessimistic concurrency conflicts

[Copilot]

APIM may return 409 PessimisticConcurrencyConflict while an API operation is still settling. Publishing should retry this transient lock instead of failing immediately.

• Retry handling

  • Route the specific conflict through the existing bounded exponential backoff.
  • Preserve hard-failure behavior for all other 409 responses.

• Regression coverage

  • Cover successful retry after the API lock clears.
  • Verify unrelated conflicts are not retried.

error.status === 409 &&
error.code === 'PessimisticConcurrencyConflict'

• Fixes 409 PessimisticConcurrencyConflict ("operation in progress") is treated as a hard failure instead of being retried #252

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Aleksey Zheltov (Alexey-Zheltov)]

Tested this locally in a dev container on top of latest main:

• npm ci / npm run build — clean, no errors
• npm test — all 60 test files passed, 1322/1322 tests passed
• Confirmed in the logs that the retry logic correctly kicks in on 409 PessimisticConcurrencyConflict, with exponential backoff as described (e.g. Request failed: HTTP 409 ... PessimisticConcurrencyConflict, retrying after ~1.1s)

Also merged this together with #256 into a combined branch to check for conflicts — no conflicts (this PR only touches src/clients/apim-client.ts, #256 only touches src/services/publish-service.ts), and all 1323 tests still pass on the combined branch.

LGTM from a testing standpoint 👍

[Aleksey Zheltov (Alexey-Zheltov)]

LGTM — retry logic correctly scoped to PessimisticConcurrencyConflict only, verified locally with full test suite passing and no conflicts with #256.