Add unique constraint on onchain_subscription_id/onchain_escrow_id to prevent double-execution

[Temi-suwa18]

Summary

Closes #56

subscriptions.onchain_subscription_id and escrows.onchain_escrow_id had no uniqueness constraint at either the DB or application layer, despite both being used as the literal on-chain contract argument identifying which real on-chain entity a keeper (subscriptions) or client-signed action (escrows) targets. If two DB rows ever shared the same onchain_subscription_id, SubscriptionService::run_due_executions's FOR UPDATE SKIP LOCKED sweep would select both independently, invoking execute_subscription twice against the same real on-chain subscription in a single keeper pass.

Changes

• Migration 011_unique_onchain_ids.sql: partial UNIQUE index on subscriptions.onchain_subscription_id and escrows.onchain_escrow_id, each WHERE ... IS NOT NULL (both columns are nullable — a row can be created before its on-chain id is known, and multiple NULLs must remain permitted). If either table already has pre-existing duplicate non-null values, the migration fails to apply rather than silently installing a constraint that doesn't hold — surfacing the conflict for manual review, per the issue's own guidance.
• SubscriptionService::create / EscrowService::create: now explicitly catch the unique-violation (via an is_unique_violation helper mirroring the existing pattern in services::batch) and return AppError::Conflict (409), instead of falling through to a generic 500.
• Tests (7 total, #[ignore]d #[tokio::test]s requiring a real Postgres via DATABASE_URL, same convention as the existing reconciliation::db_tests):
  • Duplicate onchain_subscription_id / onchain_escrow_id on create is rejected with Conflict.
  • NULL ids remain unrestricted (multiple rows with no on-chain id yet).
  • Informational (not a required fix per the issue): with the new index temporarily dropped inside a transaction that's always rolled back (reproducing the pre-fix schema), two subscription rows sharing one onchain_subscription_id are both selected by run_due_executions's exact due-selection query — demonstrating why the constraint needs to exist at the schema level.

Also fixed: migration 005 never applied cleanly (pre-existing, unrelated to #56)

While setting up a local Postgres to actually run and verify the new tests, migrations/005_add_indexes.sql turned out to reference a payments table with from_address/to_address columns that never existed under those names — the real table (001_initial.sql) is transactions, with source_account/destination_account. This blocked the entire migration chain from applying to any fresh database. Fixed to match the real schema (own commit, clearly separated from the #56 work).

Test plan

• All 11 migrations apply cleanly to a fresh Postgres 16 database.
• cargo test --bin stellarsend -- --include-ignored (real Postgres) — 34/34 relevant tests passing, including all 7 new ones. (2 pre-existing, unrelated reconciliation::db_tests failures reproduce identically on a clean upstream/main checkout before any of these changes — a missing seed-user FK and an environment-dependent assertion — confirmed out of scope.)
• cargo clippy --all-targets — no new warnings (one pre-existing warning in untouched escrow.rs code).
• cargo fmt --check — no new formatting issues introduced (pre-existing drift elsewhere in the repo, untouched).
• This repo's actual CI (cargo-deny check advisories / cargo-deny check bans licenses sources, per .github/workflows/deny.yml) — both pass locally; no dependency changes in this PR (Cargo.toml/Cargo.lock untouched).

[abayomicornelius]

All ci passed