コンポーネント／トークンのリネームが diff で「削除＋追加」になる

## 背景

`apps/web/src/lib/catalog-diff.ts` の `diffCatalogs` は **name** をキーに突合しています。これにより Figma 側でコンポーネントやトークンを **リネーム**した場合、以下のように分かれて記録されます。

```
Components: +1 / -1
+ NewName
- OldName
```

実態は 1 件のリネームでも、ログ上は「削除＋追加」に見えるため、変更履歴を遡る人にとって誤解を招きます。

## 検討案

### 案 A: id を第 2 キーとして突合
```ts
// 旧側で id 一致するエントリを優先的に「同一」とみなす
// name が変わっていれば modified.reasons に "rename: Old→New" を追加
```

ただし Figma の `id` は同期サイクル間で安定するか要確認。プラグインスキャン時に `node.id` を保持しているが、ノードを削除して再作成すると別 id になる。

### 案 B: 類似度ベースのリネーム検出
両側に「片方にしか出てこない名前」が同数あり、かつ props/variants/nodeTree の一致率が高ければリネームとみなす。実装は重め。

### 案 C: Figma 側で `meta.previousName` を持たせる
プラグイン側で前回スキャン時の名前と突き合わせ、`previousName` を payload に乗せる。サーバー側で利用。

## 推奨

まず **案 A** で id ベースの突合を試し、id 不安定が問題になるなら **案 C** に進む。

## 関連

- PR #2 のレビュー指摘から派生

Start in apps/web/src/lib/catalog-diff.ts at diffCatalogs and inspect how catalog entries are matched and how modified.reasons is built. Then trace the plugin scan payload to confirm where node.id is retained and whether it remains stable across syncs. Done means a stable-id rename is reported as one modification, while genuinely removed and added entries remain separate.

Written by the indexing model from the issue text.