Add wishlist/saved state for scraped items before wardrobe

## Problem

Scraped items appear to go straight into the wardrobe, so there is no intermediate “I like this but haven’t bought it yet” state.
Users currently cannot separate aspirational items from owned inventory, which makes planning and backloging purchases difficult.

## Impact

- Scraped products are mixed with owned wardrobe items, reducing clarity and trust.
- Users cannot easily track shopping intent or style gaps before purchase.
- The wardrobe view becomes cluttered with items that are not actually acquired.
- Increases risk of duplicate purchases, missing planned items, and poor shopping workflow.

## Proposed Fix

- Add a dedicated **Wishlist / Saved items** state for scraped products.
- On scrape (or during later item actions), allow users to save as:
- `Wardrobe` (owned)
- `Wishlist` (saved for later purchase)
- Add a new wishlist listing/filter in the UI separate from wardrobe.
- Add transitions between states:
- `Wishlist -> Wardrobe` when purchased
- `Wishlist -> Archived/Removed` when no longer needed
- Optional: `Wardrobe -> Wishlist` for rollback
- Optional setting: **Auto-save scraped items to wishlist** for planning-focused users.
- Make state visible in item cards and search/sort results.

## Functionality Impact

| Area | Current State | Requested Change |
|---|---|---|
| Scrape flow | Scraped item always lands in wardrobe | Scraped item can be saved to wishlist or wardrobe |
| Product lifecycle | No explicit “interested” state | Distinct states: wishlist, wardrobe, archived |
| UI | Single collection (wardrobe-centric) | Separate wishlist + wardrobe views/filters |
| Purchase conversion | No explicit transition action | Explicit “moved to wardrobe / marked as bought” |
| Planning | Weak intent tracking | Strong planning flow for gaps and future buys |

查找抓取流程和项目模型，以了解当前抓取的项目保存在哪里。确定项目的数据库架构，并查看是否可以添加 'state' 或 'collection' 字段。检查 Wardrobe 视图的 UI 组件，了解如何添加一个单独的 Wishlist 视图。检查现有的用于创建和更新项目的 API 端点，以添加状态转换。

由索引模型根据 Issue 内容生成。