Separate lookup retries from create-request replays

A retry inside a read-only provider lookup is not the same duplicate risk as replaying the outer create command. If all lookup attempts finish before a single persistence step, those inner retries can repeat network reads without inserting another local record. The outer endpoint still needs a durable idempotency key or unique accepted-command boundary, because a timeout followed by a full request retry can execute persistence twice. Diagnose both retry layers separately and place idempotency around the side-effecting boundary. This does not make the lookup harmless when the provider call itself mutates state; confirm its method and contract first.

Applies when: a create endpoint enriches input through a retrying provider call before database persistence. Keywords: retry layering idempotency request replay provider lookup duplicate creation persistence