Add customer.* webhook events and customer_id list filters (wave 1)

[ericviana]

What

This is wave 1 of the receivers -> customers migration for blindpay-node: only changes the currently deployed API already accepts. Nothing here requires blindpay-v2 PR #1799 (still open, not deployed) to be merged first.

• WebhookEvents: add customer.new, customer.update, customer.delete as new union members. Mark receiver.new, receiver.update, receiver.delete @deprecated in place with a trailing comment (a plain string-literal union can't carry per-member JSDoc). The receiver.* members are NOT removed, they still fire in production today.
• ListPayinsInput / ListPayoutsInput: add an optional customer_id filter alongside the existing receiver_id. customer_name is intentionally NOT added to these two, the deployed API does not accept it there.
• customers resource list(): delete the customer_id/customer_name -> receiver_id/receiver_name query-param translation shim. The deployed GET /v1/instances/{instance_id}/customers endpoint already accepts customer_id and customer_name natively, so the translation is now a no-op that was only adding indirection.
• CLAUDE.md: fix three stale doc examples (UpdateReceiverInput/DeleteReceiverInput naming table, an offramp-wallet example still showing /receivers/{receiver_id} paths, a create-customer example still POSTing to /receivers) that no longer match what the code actually does.

Also fixes: pre-existing wrong response field names

Independent of the receivers -> customers migration, a previous change had optimistically renamed some response field declarations to customer_id ahead of the server. The deployed API still sends receiver_id in these places today, so the SDK was declaring a key that never arrives on the wire (Python/Swift hard-fail on this; TypeScript silently resolves to undefined). Confirmed each one directly against the deployed openapi.json before fixing:

• ListBlockchainWalletsResponse / GetBlockchainWalletResponse / CreateBlockchainWalletResponse: schema BlockchainWalletOut has receiver_id in required, no customer_id.
• OfframpWallet (used by list/get offramp wallet responses): schema OfframpWallet has receiver_id in required, no customer_id.
• GetLimitIncreaseRequestsResponse: schema GetReceiverLimitIncreaseOut has receiver_id, no customer_id.
• The nested Owner type on customers.get() / customers.list() for business customers: schema ReceiverOut.owners[] nests receiver_id, no customer_id.

These are safe to land in wave 1 (unlike the wave 2 renames below) because they align the SDK with what production sends today, not with the not-yet-deployed rename. Request-side customer_id path/body params are untouched, they're correct since routes are already /customers/.... receiver_amount, currency_type, and the bank-accounts owner-id field are untouched too, the latter is a separate pre-existing type-accuracy issue (deployed BankAccountOut has neither receiver_id nor customer_id) left out of scope here.

Test fixtures updated to match, and the offramp wallet fixtures now carry explicit type annotations so a regression of this exact bug fails check-types.

Why this is safe today

I diffed the deployed API's openapi.json against this PR's changes before making them:

• customer.new/customer.update/customer.delete are already in the deployed WebhookEndpointIn.events enum and the API has been dual-emitting both receiver.* and customer.* events since June.
• GET /v1/instances/{instance_id}/payins and .../payouts already list customer_id as an accepted query parameter (verified per-endpoint; customer_name is only accepted on .../customers, not on payins/payouts).
• GET /v1/instances/{instance_id}/customers already lists both customer_id and customer_name as accepted query parameters, alongside the legacy receiver_id/receiver_name.

Purely additive, purely deprecation-marking, plus the response-field corrections above. No existing consumer's code path changes shape.

What is deliberately NOT in this PR (wave 2)

The remaining 11 receiver_* -> customer_* body/response field renames (customer_local_amount, customer_wallet_address, customer_network, customer_token, customer_invite_redirect_url, receiver_id on payin/payout/transfer responses, etc.), the RECEIVERS_* -> CUSTOMERS_* error-code/message renames, and removal of receiver.* from the webhook enum, are all held back on purpose. The deployed API does not accept the renamed field names yet, they only land once blindpay-v2 PR #1799 ships. Shipping those today would break every current SDK user sending receiver_* fields.

Build output

$ bun install --frozen-lockfile
Checked 247 installs across 293 packages (no changes)

$ bun run check-types
tsc --noEmit
(no errors)

$ bun run lint:check
Checked 50 files in 31ms. No fixes applied.

$ bun run test
 Test Files  20 passed (20)
      Tests  97 passed (97)

Version

Bumped package.json to 4.1.0 (minor, additive) and added a changeset (.changeset/customer-webhooks-and-list-filters.md), matching this repo's existing convention (e.g. #54 bumped package.json directly alongside its changeset in the same PR). Not bumped again for the field-name fixes added on top, they're covered by the same wave-1 minor bump.

https://claude.ai/code/session_01F1stiNzuNtJXoXtiW9ZCbs

[BernardoSM]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[ericviana]

Added a second commit on top of the wave 1 work: fixed four response field declarations that had been renamed to customer_id optimistically, ahead of the server-side rename (blindpay-v2 PR #1799, still open and not deployed). The deployed API sends receiver_id in these places today, so the SDK was declaring a key that never arrives on the wire.

Confirmed each one directly against the deployed openapi.json before touching anything:

• ListBlockchainWalletsResponse / GetBlockchainWalletResponse / CreateBlockchainWalletResponse -> schema BlockchainWalletOut has receiver_id in required, no customer_id.
• OfframpWallet (list/get offramp wallet responses) -> schema OfframpWallet has receiver_id in required, no customer_id.
• GetLimitIncreaseRequestsResponse -> schema GetReceiverLimitIncreaseOut has receiver_id, no customer_id.
• Nested Owner type on customers.get()/customers.list() for business customers -> schema ReceiverOut.owners[] nests receiver_id, no customer_id.

These are wave-1 safe: they align the SDK with what production sends today, they don't depend on PR #1799 shipping. Request-side customer_id path/body params are untouched (correct, matches the already-deployed /customers/... routes). receiver_amount and currency_type are untouched everywhere. I also checked the bank-accounts owner-id field, the deployed BankAccountOut schema has neither receiver_id nor customer_id, so that's a separate pre-existing type-accuracy issue, left out of scope here.

Updated the test fixtures for all four, and added explicit type annotations to the offramp wallet fixtures so a regression of this exact bug would fail check-types (verified by reverting the fix locally and re-running bun run check-types, it correctly failed).

bun install --frozen-lockfile && bun run check-types && bun run lint:check && bun run test all pass (97 tests). No version bump beyond the existing wave-1 4.1.0.