[Frontend] Add retry policy with idempotency awareness to the API client

## Problem

Transient failures are handled inconsistently and naive retries could duplicate bookings, payments, or records.

## Relevant code

`src/lib/api`

## Proposed scope

Retry only safe/idempotent operations by default, honor Retry-After, and require idempotency keys for eligible mutations.

## Acceptance criteria

- [ ] The reported behavior is reproduced or characterized with a focused automated test before the fix.
- [ ] The implementation satisfies the proposed scope without weakening TypeScript, lint, authorization, privacy, or error handling.
- [ ] Success, empty/loading where applicable, failure, and boundary cases are covered.
- [ ] Existing related tests pass and new regression coverage is included.
- [ ] User-facing behavior remains accessible by keyboard and at mobile viewport sizes where UI is affected.
- [ ] Documentation is updated when the change alters configuration, contracts, security assumptions, or contributor workflow.

## Contributor notes

Base the work on the latest `main` branch. Keep unrelated refactors out of the pull request and include screenshots or recordings for visible changes. Never use real pet, medical, contact, wallet, or credential data in fixtures.

Start in src/lib/api and first characterize the reported retry behavior with a focused automated test. Trace how operations, Retry-After, and idempotency keys are currently represented before defining the affected client entry points. Done means safe operations retry by default, eligible mutations require idempotency keys, and related regression, boundary, error-handling, and contract tests pass.

Written by the indexing model from the issue text.