fix: enforce WBGL bridge reserve limit

[Sikkra]

Summary

Prevents users from sending WBGL when the requested amount exceeds the bridge service's reported BGL reserve.

The WBGL-to-BGL flow already fetches the current BGL reserve from /submit/wbgl, but the send form only checked the user's WBGL balance. This PR adds a reserve-side validation before calling sendWbgl(), keeps the transaction from being submitted when the bridge cannot cover it, and shows the actual available BGL amount in the field helper text.

Verification

• CI=true npm test -- --watchAll=false in app/ (1 passed)
• git diff --check
• node --openssl-legacy-provider ./node_modules/react-scripts/scripts/build.js in app/ (compiled with existing warnings)

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

USDT-TRC20 payout address if accepted: TPwPFww7zxXFQ7zugo22gktQhckWVarRqi

[MyTH-zyxeon]

Maintainers - this looks like a narrow, reviewer-friendly Bitgesell improvement-program candidate tied to bitgesell#81 and bridge issue #20.

Why this PR seems materially useful:

• The WBGL-to-BGL flow already fetches reserve data from /submit/wbgl, so adding a reserve-side guard in the send form closes a real UX/correctness gap instead of inventing a new policy.
• The patch keeps the behavior local to one component plus one focused regression test; it does not widen into wallet, service, or chain-level refactors.
• The new helper text makes the rejection state actionable for users by surfacing the actual available BGL amount instead of allowing a doomed send attempt.

Suggested acceptance checks:

1. When amount > bridge reserve, sendWbgl() is never called and the form shows the current reserve clearly.
2. When amount <= user WBGL balance and <= bridge reserve, the existing happy path still submits unchanged.
3. The reserve value formatting stays stable for non-integer balances and does not regress into misleading trailing-zero output.
4. If the reserve fetch can briefly return 0 or stale data, confirm that blocking the send is the intended fail-safe rather than letting the transaction proceed optimistically.

From the public metadata, this PR is currently OPEN, MERGEABLE, and mergeStateStatus=CLEAN, with no visible review discussion when I checked from my side.