fix(core): preserve temporary error semantics in BatchDeleter zero-success path

[TennyZhuang]

Which issue does this PR close?

N/A - Follow-up to #7401. Found through deterministic state machine testing of BatchDeleter.

Rationale

When delete_batch() returns zero successes but all individual failures are temporary errors, flush_buffer() returns a hardcoded permanent error:

return Err(Error::new(
    ErrorKind::Unexpected,
    "batch delete returned zero successes",
));

This kills retry semantics: callers (including retry layers) see a permanent error and give up, even though all underlying failures are temporary and could succeed on retry.

Changes

• Modified flush_buffer() to check whether all failures in the zero-success case are temporary. If so, the returned error is marked temporary via set_temporary().
• Added a regression test with a mock that returns all-temporary failures on the first call and all successes on retry, verifying that the error is correctly marked temporary.

Are there any user-facing changes?

Retry layers will now correctly retry batch delete operations when all individual failures are temporary, instead of treating them as permanent failures.

---

This change was generated with the assistance of an AI coding agent.

🤖 Generated with Claude Code