Use the Inspired visual search guide to review the integration in this
repository before we ship it.

Work through it in this order:

1. Read sections 2 and 3 of the guide, then find where we call Inspired. Tell
   me whether we are on POST /api/v1/jobs or POST /api/v1/inspire, and if it is
   the synchronous route, what it would take to move.
2. Check how we poll. We should be reading pollAfterMs out of each response
   rather than using a fixed interval, and we should be rendering the object
   list from progress.items as soon as it exists instead of holding a spinner
   until the read completes.
3. Check the domain. We should pass one explicitly rather than inheriting the
   fashion default, and we should handle the 400 an unknown domain returns —
   that response means nothing was charged, so it must not be retried blindly.
4. Run section 5 against our result handling. Specifically: do we re-sort
   candidates anywhere, do we treat an empty items array as an error, and does
   any user-facing string say "identified", "found", "exact" or "match" where
   the guide requires "spotted" and "visually similar"?
5. Check what we do with candidates[].imageUrl. Those are retailer and Google
   URLs and they expire; anything we persist has to be re-hosted.
6. Finish with the section 10 checklist as a list of pass or fail, and open a
   task for each failure with the guide section that explains it.

Do not change the pipeline's latency expectations to make our UI look better.
A full read is minutes by design, and the guide's answer to that is progressive
disclosure, not a shorter timeout.