No test coverage for SponsorshipOperations.jsx and ThresholdSettings.jsx, which configure account-security-critical Stellar operations

[Mystery-CLI]

Background

frontend/src/components/SponsorshipOperations.jsx (Stellar reserve sponsorship, per the closed #780) and frontend/src/components/ThresholdSettings.jsx (account signing thresholds, per the closed #789) both configure account-level settings with real security consequences if misconfigured — thresholds in particular directly control how many signatures are required to authorize future transactions on the account. Neither has a test file.

Problem

• ThresholdSettings.jsx in particular is high-stakes: an error in how the UI constructs a setOptions operation's threshold values could lock a user out of their own account (setting a threshold higher than the combined weight of their available signers) or, conversely, weaken account security below what the user intended — and there's currently no automated check that the values displayed/submitted match Stellar's actual threshold semantics (low/medium/high threshold categories, signer weights).
• SponsorshipOperations.jsx similarly has no coverage for correctly constructing begin/end sponsorship operation pairs.

Proposed Solution

Add component tests for both, with ThresholdSettings.jsx prioritized given the account-lockout risk.

Implementation Steps

1. Add ThresholdSettings.test.jsx covering: the low/medium/high threshold fields map correctly to the constructed setOptions operation, and a client-side warning/confirmation appears if the user is about to set a threshold that would exceed their current signers' combined weight (or, if that safeguard doesn't currently exist, file it as a related follow-up rather than silently asserting it).
2. Add SponsorshipOperations.test.jsx covering correct begin/end-sponsorship operation pairing.
3. Wire both into the existing CI test run.

Acceptance Criteria

• ThresholdSettings.jsx's operation construction is covered by a test.
• SponsorshipOperations.jsx's operation construction is covered by a test.
• If no client-side lockout safeguard exists for threshold changes, that gap is explicitly noted (and filed separately if warranted) while writing the tests.

Notes

Good first issue, though the threshold-lockout-safeguard question raised while writing the test may be worth escalating to its own issue if the safeguard turns out to be missing.