Add DOM-scraping fallback for when Vinted's wardrobe API 403s

A real, logged-in test hit a 403 on the wardrobe API for that specific
authenticated session, while the exact same endpoint/user ID succeeds
anonymously (verified both ways against the real account). Most likely
a stricter anti-bot/CSRF check that triggers for some authenticated
sessions and not others - not reliably reproducible, so chasing the
exact cause further wasn't going to be productive.

Instead, made the Vinted bookmarklet resilient to it: try the
wardrobe API first (fast, complete count, clean structured fields),
and if it fails for any reason, fall back to the scroll-and-scrape-
the-DOM approach that was already working before the API rewrite
(same size-based avatar filtering and patient scroll-stability logic
already validated). Best case gets the clean fast path; worst case
still works, just slower and without the API's cleaner size/condition
data.

Verified both paths independently against the real account this was
reported against: the wardrobe API (149/149 items) and, with the API
call deliberately forced to fail, the DOM-scraping fallback (correct
brand/size/condition/photos, no avatar contamination).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>