fix: run fetch cleanup after network errors

[tolga-tom-nook]

Summary

• Ensures fetchQuery runs its callbackAlways cleanup when fetch() rejects before a JSON response is available.
• Prevents send-form callers from staying disabled after network/CORS/RPC connectivity failures.

Why

send() disables the form fieldset before submitting sendrawtransaction and relies on callbackAlways to re-enable it. The success/error-response path already called the cleanup, but the .catch() path only showed the SweetAlert error. A rejected network request could therefore leave the wallet send form disabled until page refresh.

Validation

• npm test passed
• git diff --check clean

Related Bitgesell bounty/improvement program: BitgesellOfficial/bitgesell#81 and BitgesellOfficial/bitgesell#39.

Payout address, if accepted: 0x4a76c7E64C08cF29B59eFC640b4ada97A270d428 (EVM/USDT-compatible).

Follow-up hardening (2026-06-08)

• Added test/fetch_query_cleanup_test.js, a focused Node/vm regression harness that proves a rejected fetch() runs callbackAlways exactly before rendering the SweetAlert error and that JSON error responses still run cleanup exactly once.
• Expanded npm test to run ESLint on the regression harness plus the executable cleanup tests.

Validation after follow-up commit a34b4c0:

• npm test
• node --check test/fetch_query_cleanup_test.js
• git diff --check

[MyTH-zyxeon]

Maintainer-facing review assist for bitgesell-wallet #7 / Bitgesell #81. I am not claiming this bounty here; I reviewed the visible public diff only, without installing dependencies, opening the wallet UI, using credentials, querying a live node/RPC, or performing any chain action.

This looks like a strong small correctness fix: fetchQuery(...) already used callbackAlways in the JSON success/error path, but a rejected fetch() could previously leave send-form cleanup stranded. Adding the same cleanup to .catch() is the right shape for the disabled-fieldset bug described in the PR body.

A few checks I would keep visible before merge/acceptance:

1. Please confirm callbackAlways is idempotent in the current callers. This diff makes the reject path match the response path, which is good, but if any caller mutates UI state in a non-idempotent way it is worth proving the cleanup stays safe when future refactors add retries/duplicate failure handling.
2. The current validation text says npm test passed, but this one-line change touches a user-facing failure path that is easy to miss in happy-path tests. If the existing suite does not directly cover a rejected fetch() branch, I would add or manually verify one scenario where sendrawtransaction fails before any JSON body exists and the fieldset becomes usable again.
3. Since the .catch() path also appends the CORS-help message, maintainers may want to sanity-check that the callback cleanup runs before the SweetAlert renders, so users can immediately retry after dismissing the error instead of being left in a stale disabled state.
4. For payout hygiene under #81, I would treat this as a focused wallet UX/reliability slice rather than a broad wallet feature change. The diff is only one line, but it fixes a real stuck-form failure mode if the manual repro in the PR body is accurate.

Suggested merge bar: confirm the existing send() cleanup callback is idempotent, verify one real rejected-request retry path, and then this should be a low-risk queue item to clear.

[tolga-tom-nook]

Follow-up hardening pushed in a34b4c0: added a focused executable regression harness for the network-rejection cleanup path. It verifies callbackAlways runs before the SweetAlert error on rejected fetches, verifies JSON error responses still run cleanup exactly once, and expands npm test to run the harness. Validation passed: npm test, node --check test/fetch_query_cleanup_test.js, and git diff --check.