Bug: Wallet repair - key validation, error handling, tests, recommendation gating, and multi-coin support

[QuickMythril]

Summary:

The wallet repair functionality needs consistency and safety improvements across validation, error handling, testing, and feature coverage. Today it accepts public keys in places where only private keys can perform a sweep, it can return ambiguous success-like responses on failure, test coverage doesn’t detect regressions, and it will perform a sweep even when it isn’t necessary. Additionally, the repair feature is only implemented for Litecoin, leaving other supported coins without equivalent behavior.

Repair accepts public keys (xpub/tpub)

• What’s wrong: Repair endpoints are documented/implemented in a way that implies xpub/tpub are acceptable, even though a sweep requires signing and thus a private key.
• Cause: The repair path does not enforce deterministic private key validation; it relies on downstream wallet operations that expect private keys.
• User impact: Users can submit xpub/tpub and receive errors or non-transaction responses, making the endpoint appear broken or misleading.
• Fix: Validate the incoming key as a deterministic private key before attempting repair. If invalid, return INVALID_PRIVATE_KEY.

Failure does not return proper API errors

• What’s wrong: On failure, repair can return a non-txid string or HTTP 200, instead of a clear API error.
• Cause: Exceptions are swallowed or translated into string results instead of surfacing API-level error responses.
• User impact: Clients cannot reliably distinguish success from failure, and automated workflows can treat failures as successful txids.
• Fix: Catch exceptions and map them to existing API errors (e.g., FOREIGN_BLOCKCHAIN_BALANCE_ISSUE, FOREIGN_BLOCKCHAIN_NETWORK_ISSUE). Use ApiExceptionFactory consistently.

Tests only check “non-null”

• What’s wrong: The current tests only assert that a response is non-null, which would pass even if the response is an error string or malformed.
• Cause: Tests are too loose and don’t validate txid format or failure behavior.
• User impact: Regressions can slip through without detection.
• Fix: Strengthen tests to validate txid format (e.g., parse as hash), add API-level tests for preview and force-gated repair behavior, and ensure negative cases assert specific API errors.

Repair runs even when it isn’t needed

• What’s wrong: The repair endpoint currently sweeps all UTXOs to the primary address regardless of whether the “old vs current” scan shows missing funds.
• Cause: There is no recommendation or preview step; repair always proceeds.
• User impact: Unnecessary on-chain transactions and fees, and potentially confusing behavior for users who don’t need the repair.
• Fix: Add a preview endpoint that compares old vs current scanning results and computes whether a repair is recommended. Gate repair by default on this recommendation, with an explicit force=true override.

Repair is only available for Litecoin

• What’s wrong: Repair/preview exists only for LTC, leaving other coins (BTC, DOGE, DGB, RVN) without equivalent support.
• Cause: The functionality was implemented in LTC resource only.
• User impact: Users on other coins cannot diagnose or repair legacy wallets consistently.
• Fix: Implement the same preview and repair logic for BTC, DOGE, DGB, and RVN, using shared Bitcoiny logic and consistent validation/error handling.