fix(batch): only fall back to direct Horizon on network-layer errors (#14)

[ghzhost]

Problem (fixes #14)

useBatchPayment's batchPaymentApi.send catch block previously swallowed every error and blindly resubmitted the already-signed XDR straight to Horizon, regardless of error type.

This caused two concrete failure modes:

1. 4xx validation error (e.g. sanctioned recipient, insufficient trustline): the backend explicitly rejected the payload, but the code pushed it straight to the public ledger, bypassing the validation.
2. 5xx / 502 after successful backend broadcast: the backend may have already submitted the transaction on-chain; the fallback resubmission gets tx_bad_seq and the user sees a confusing error at exactly the point where the payment actually worked.

Fix

src/lib/api.ts

• Added optional httpStatus?: number field to ApiRequestError, populated by normalizeApiError from the Axios response status. A missing httpStatus unambiguously identifies a pure network-layer failure (no server response arrived).
• New exported helper isNetworkLayerError(error) encapsulates the check in one unit-testable place.

src/hooks/useBatchPayment.ts

• The catch block now calls isNetworkLayerError and only falls back to submitTransaction when it returns true (no HTTP response = backend never received the request).
• 4xx, 5xx, and 502 errors are re-thrown so the caller sees a real, actionable error.

Tests added

src/hooks/useBatchPayment.test.tsx — 10 tests:

• Normal backend-success path (no Horizon call)
• Pure network error → fallback triggers, Horizon called once
• 400 validation → error surfaced, Horizon not called
• 500 server → error surfaced, Horizon not called
• 422 unprocessable → error surfaced, Horizon not called
• 502 bad gateway → error surfaced, Horizon not called
• isNetworkLayerError unit tests (with/without status, non-ApiRequestError)

All 123 existing tests still pass.