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.

The issue is in `crates/node/src/node/grpc/mod.rs` around line 197-199 in the `store_note` function. Look for the UNIQUE constraint error handling. The fix is to catch the `ConstraintViolation` error and return a successful response or an `ALREADY_EXISTS` status. Check the database API for `note_exists` to understand the context. Test by attempting to send a duplicate note and verifying the response.

Vom Indexierungsmodell aus dem Issue-Text verfasst.