SendNote is not idempotent — duplicate send returns INTERNAL

Severity: high (correctness / retry safety).

### Summary

The schema has `id BLOB NOT NULL UNIQUE`, so re-sending the same note hits a UNIQUE constraint. `store_note` maps every error to `Status::internal(format!("Failed to store note: {e:?}"))` (`crates/node/src/node/grpc/mod.rs:197-199`), so a duplicate comes back as `INTERNAL: Failed to store note: ConstraintViolation(...)`.

### Impact

The standard retry-after-timeout pattern (first attempt committed, ack lost) makes the retry fail with a scary internal error. Wallets cannot distinguish "already delivered" from "server broken", which pushes clients toward *not* retrying — bad when this service is the sole holder of the payload. (`note_exists` exists in the DB API but no handler calls it.)

### Recommendation

Catch the `ConstraintViolation` in `send_note` and return `Ok(SendNoteResponse{})` (idempotent success) or `ALREADY_EXISTS`. Document `SendNote` as idempotent on `NoteId`.

---
Part of #114.

問題は `crates/node/src/node/grpc/mod.rs` の `store_note` 関数内、197-199行目付近にあります。UNIQUE制約のエラーハンドリングを探してください。修正は、`ConstraintViolation` エラーをキャッチし、成功レスポンスまたは `ALREADY_EXISTS` ステータスを返すことです。コンテキストを理解するために、データベースAPIの `note_exists` を確認してください。重複したノートを送信しようとしてレスポンスを検証することでテストします。

索引モデルが issue の本文から書いたものです。