fix: cover submitted WBGL transaction errors

[Sikkra]

Summary

Covers submitted WBGL transaction error paths that could leave conversions stuck in pending:

• reject sendWBGL() when sendSignedTransaction emits an error so callers can enter their existing return/error handling path
• mark mined failed receipts as error instead of treating every receipt as eventually successful
• expire long-missing submitted receipts after a configurable number of one-minute checks (PENDING_TX_MAX_CHECKS, default 180, 0 disables)
• add focused helper coverage for receipt failure and pending-expiry decisions

Verification

• node --check service/src/modules/chores.js service/src/modules/web3.js service/src/utils/config.js service/src/utils/transactionStatus.js service/src/tests/transactionStatus.js
• npx mocha src/tests/transactionStatus.js --timeout 10000 in service/ (4 passing)
• git diff --check

Note: npx eslint ... is not a useful verifier in the current repo because the existing ESLint setup fails to parse ES module import syntax before it reaches the actual changes.

Related: #21
Program reference: BitgesellOfficial/bitgesell#81

USDT-TRC20 payout address if accepted: TPwPFww7zxXFQ7zugo22gktQhckWVarRqi

[MyTH-zyxeon]

Maintainers - this looks like a meaningful bridge-service reliability fix under the Bitgesell improvement lane (bitgesell#81), and it seems stronger than a docs-only cleanup because it closes real stuck-transaction paths.

What looks materially useful from the public diff:

• sendWBGL() now rejects on sendSignedTransaction errors instead of only logging them, so callers can move into the existing return/error flow instead of leaving the conversion stranded.
• Pending submitted WBGL transfers can now age out after PENDING_TX_MAX_CHECKS one-minute polls, which gives operators a deterministic error path when a receipt never appears.
• Failed receipts are treated as error rather than implicitly waiting forever for success.
• The new helpers/tests keep the receipt-status and pending-expiry logic explicit instead of burying it in the long chores loop.

Acceptance checks I would keep explicit before merge/payout:

1. When sendSignedTransaction emits an error before a tx hash, the conversion ends in the existing error/return path and does not remain silently pending.
2. A mined receipt with status=false / 0x0 is marked error and is not later promoted to sent.
3. PENDING_TX_MAX_CHECKS=0 really disables expiry, while the default 180 behaves as documented in both config and README.
4. If README/setup docs are being touched anyway, confirm the new env var description matches the real service behavior and units exactly (one poll per minute).

From the public metadata when I checked: OPEN, MERGEABLE, mergeStateStatus=CLEAN, and there were no prior visible PR comments/reviews on this thread. I did not run bridge services, install dependencies, use wallet keys, call live RPC endpoints, or perform any live-chain action here; this is a maintainer-facing review-assist note to help route a clean decision on #38.