"Receivers" to "Customers" migration: final notice and complete guide

Migrate this codebase off the deprecated BlindPay "receivers" API surface and onto
"customers". This is a rename of the API surface only: resource IDs are unchanged.

Work through the steps in order and show me a diff before applying anything.

STEP 1 - Find every call site.
Search the whole repo (including tests, fixtures, recorded HTTP cassettes, env
files, OpenAPI/Postman collections, infrastructure config, and docs) for:
  receivers, receiver_, receiverId, RECEIVERS_, "receiver." (webhook event names)

STEP 2 - Rewrite URL paths.
  /v1/instances/{id}/receivers               -> /v1/instances/{id}/customers
  /v1/e/instances/{id}/receivers             -> /v1/e/instances/{id}/customers
  /v1/instances/{id}/limits/receivers/{rid}  -> /v1/instances/{id}/limits/customers/{rid}
  /v1/instances/{id}/external-receiver-token -> /v1/instances/{id}/external-customer-token
Apply to all sub-resources as well: bank-accounts, wallets, blockchain-wallets,
virtual-accounts, offramp-wallets, limit-increase, rfi.
The old paths still answer 301, so nothing breaks immediately, but every call
costs an extra round-trip until this is done.

STEP 3 - Rename request and response fields.
  receiver_id                      -> customer_id
  receiver_name                    -> customer_name
  receiver_local_amount            -> customer_local_amount
  receiver_wallet_address          -> customer_wallet_address
  receiver_network                 -> customer_network
  receiver_token                   -> customer_token
  receiver_invite_redirect_url     -> customer_invite_redirect_url
  receiver_rfi_emails_enabled      -> customer_rfi_emails_enabled
  receivers_amount                 -> customers_amount
  receiver_type                    -> customer_type
  receiver_kyc_status              -> customer_kyc_status
  receiver_aiprise_session_id      -> customer_aiprise_session_id
  receiver_aiprise_user_profile_id -> customer_aiprise_user_profile_id

STEP 4 - CRITICAL EXCEPTION. Do NOT rename receiver_amount.
receiver_amount (singular) is still called receiver_amount on quotes, payins,
payouts, and transfers. It means "amount the receiving side gets", not a
reference to the customer resource. Renaming it will break those calls.
Note the near-miss: receivers_amount (plural, the customer count on
GET /v1/instances) IS renamed to customers_amount. Handle each explicitly.
Never run a blanket s/receiver/customer/ over this repo.

STEP 5 - Rename webhook event names and handlers.
  receiver.new    -> customer.new
  receiver.update -> customer.update
  receiver.delete -> customer.delete
Payloads are identical. Also update the subscription list in the BlindPay
dashboard; a code-only change will leave your endpoint silent.
The old dual-emit is gone, so if a handler was de-duplicating receiver.* against
customer.* for the same action, that workaround can be removed.

STEP 6 - Rename error codes checked in code.
Any comparison against the code field on an error response:
  RECEIVERS_NOT_FOUND -> CUSTOMERS_NOT_FOUND, and the same CUSTOMERS_ prefix
  swap for ALREADY_APPROVED, KYC_NOT_APPROVED, ONBOARDING_INCOMPLETE,
  INVALID_DATA, INVALID_PHONE, INVALID_TAX_ID, ID_DOCUMENT_INVALID,
  COUNTRY_NOT_SUPPORTED, ENHANCED_KYC_REQUIRED,
  BUSINESS_ENHANCED_NOT_AVAILABLE.

STEP 6b - Rename error message slugs checked in code.
If you branch on the message field instead of code, these changed too:
  receiver_not_found            -> customer_not_found
  receiver_id_not_found         -> customer_id_not_found
  receiver_already_approved     -> customer_already_approved
  receiver_kyc_not_approved     -> customer_kyc_not_approved
  receiver_not_approved         -> customer_not_approved
  receiver_limit_not_found      -> customer_limit_not_found
  receiver_already_has_limit_increase_in_review
    -> customer_already_has_limit_increase_in_review
  vm_invalid_receiver_data      -> vm_invalid_customer_data
  vm_receiver_country_not_supported -> vm_customer_country_not_supported
  vm_unsupported_receiver_type  -> vm_unsupported_customer_type
  zenus_business_va_requires_business_receiver
    -> zenus_business_va_requires_business_customer
  beneficiary_name_must_match_receiver_for_first_party
    -> beneficiary_name_must_match_customer_for_first_party
  blockchain_wallet_does_not_belong_to_receiver
    -> blockchain_wallet_does_not_belong_to_customer
  sender_and_receiver_networks_must_be_the_same
    -> sender_and_customer_networks_must_be_the_same
  sender_and_receiver_tokens_must_be_the_same
    -> sender_and_customer_tokens_must_be_the_same
Leave unchanged: any slug mentioning receiver_amount, and
otc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees.

STEP 6c - Do NOT change the currency_type request value.
currency_type still accepts 'sender' and 'receiver'. Sending 'customer' is
invalid. This pairs with the receiver_amount exception in step 4.

STEP 7 - Update the SDK accessor, if you use an official SDK.
  blindpay.receivers.*  ->  blindpay.customers.*
  blindpay.receivers.bankAccounts.create(...)
    ->  blindpay.customers.bankAccounts.create(...)
Method signatures are identical; only the accessor renames. Bump to the latest
release of your current major, which added customers with no import changes.

STEP 8 - Do NOT touch stored IDs.
Customer IDs keep the re_ prefix (re_abc123456789). Leave every stored ID,
fixture, and database value exactly as it is. There is no data migration.

STEP 9 - Verify.
  - grep the repo: no receivers, receiver_id, or receiver.* webhook names left
  - confirm receiver_amount is still present and untouched wherever it was before
  - run the test suite, and update fixtures or cassettes that assert on renamed
    fields
  - check logs for 301 responses from api.blindpay.com; each one is a path you
    missed

Report anything ambiguous rather than guessing.