Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/data/models/enums/cant_do_reason.dart`:
- Around line 26-27: The switch that formats/displayes CantDoReason values in
lib/features/trades/widgets/mostro_message_detail_widget.dart doesn't handle the
new enum value CantDoReason.tooManyRequests, so it falls through to default; add
a case for CantDoReason.tooManyRequests in the same switch (or the helper that
maps CantDoReason to UI text) and return the appropriate localized message using
the same localization pattern used for other cases (match how pendingOrderExists
is handled) so users see the specific "too many requests" reason instead of the
generic default.

In `@lib/features/restore/restore_manager.dart`:
- Around line 980-982: The catch in syncTradeIndex currently logs only the error
object; change the handler to capture the stack trace (use catch (e,
stackTrace)) and pass it into the logger.e call (e.g., logger.e('syncTradeIndex:
failed', error: e, stackTrace: stackTrace)) so failures include stack traces
like the rest of restore_manager.dart.
- Around line 956-987: syncTradeIndex mutates shared instance fields
(_tempSubscription, _tempTradeKey, _masterKey, _currentStage) that
initRestoreProcess also uses, causing race conditions; either serialize the
operations with an operation-level lock or make syncTradeIndex use only local
variables and avoid touching those shared fields. Add a simple mutex/flag (e.g.,
a private Future<void>? _syncLock or bool _syncInProgress) and await/guard
around the critical section in syncTradeIndex (or refactor to use local vars for
tempSubscription/tempTradeKey/masterKey/currentStage and only read/write
persistent state via keyManager/setCurrentKeyIndex), ensuring you still cancel
the local subscription and clear local state in finally without altering the
shared fields used by initRestoreProcess.

---

Nitpick comments:
In `@lib/features/order/notifiers/add_order_notifier.dart`:
- Around line 49-54: The branch handling terminal errors currently treats
invalidTradeIndex alongside invalidFiatCurrency but uses fiat-specific wording;
update the logic around CantDo handling (referencing CantDo, CantDoReason, and
the _resetForRetry() call) to treat terminal errors generically: rename any
variable/comment/log message that mentions fiat to something like "terminal
error" or "invalid request parameter", and update logging/messages for the else
branch (the path checking CantDoReason.invalidFiatCurrency and
CantDoReason.invalidTradeIndex) so it describes a generic terminal error instead
of fiat-specific wording to make debugging accurate.

In `@lib/shared/providers/app_init_provider.dart`:
- Around line 24-29: The current desync check uses keyManager.tradeKeyIndex == 1
which can be a valid state; instead gate the sync on an explicit “missing
persisted index” signal: replace the condition with hadMasterKey &&
!keyManager.hasPersistedTradeIndex (or hadMasterKey &&
keyManager.persistentTradeIndex == null) and keep the call to
unawaited(ref.read(restoreServiceProvider).syncTradeIndex()); if KeyManager
lacks a hasPersistedTradeIndex/persistentTradeIndex accessor, add one to
KeyManager and use it here so we only call syncTradeIndex() when the persisted
index is actually absent.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/features/restore/restore_manager.dart`:
- Around line 824-826: initRestoreProcess() must guard against concurrent
operations like syncTradeIndex() to avoid corrupting shared state
(_tempSubscription, _currentCompleter, etc.); add a check at the start of
initRestoreProcess() that returns/fails early (and logs) when
_operationInProgress is true instead of setting _operationInProgress = true
unconditionally, so the method only proceeds when no other operation is active
and then sets _operationInProgress before touching shared fields.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/features/restore/restore_manager.dart`:
- Around line 988-993: The code currently skips persisting when
response.tradeIndex == 0, so wallets with no prior trades never get the default
persisted; update the syncTradeIndex path to always persist the default index
instead of only when response.tradeIndex > 0 — call
keyManager.setCurrentKeyIndex(response.tradeIndex + 1) (and log via logger.i)
for tradeIndex == 0 as well (e.g., change the conditional or remove it) so the
defaulted value is written to storage and prevents repeated resync on cold
start.
- Around line 984-985: A race occurs because _sendLastTradeIndexRequest() can
trigger a reply before _currentCompleter is set by _waitForEvent(), causing
_handleTempSubscriptionsResponse() to drop the event; fix by arming the awaiting
mechanism before sending the request: create or initialize the completer for
RestoreStage.gettingTradeIndex (i.e. invoke the logic that _waitForEvent() would
set up) prior to calling _sendLastTradeIndexRequest(), then call _waitForEvent()
or await the already-created completer; reference the methods
_sendLastTradeIndexRequest(), _waitForEvent(),
_handleTempSubscriptionsResponse(), and the
_currentCompleter/RestoreStage.gettingTradeIndex symbols when making the change.
- Around line 824-828: The guard in initRestoreProcess that returns false when
_operationInProgress is true causes silent no-ops upstream (caller doesn’t check
the bool); change initRestoreProcess (and related call sites) so that instead of
silently returning false it either awaits the active operation to finish or
throws a handled error. Concretely, replace the early return on
_operationInProgress in initRestoreProcess with one of: 1) wait for the existing
operation to complete (e.g., track an in-progress Future/Completer and await it)
and then proceed to run syncTradeIndex()/restore logic, or 2) throw a specific
exception (e.g., RestoreInProgressException) so callers can surface a
user-facing error; update callers that currently ignore the boolean to handle
the thrown exception if you choose option 2. Ensure you reference and update the
_operationInProgress flag, the in-progress Future/Completer you add, and the
initRestoreProcess method so restores are not silently skipped.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@lib/features/restore/restore_manager.dart`:
- Around line 1012-1018: The finally block in syncTradeIndex() should mirror
initRestoreProcess() by clearing the shared cleanup state; specifically, add
resetting _currentCompleter to null in the finally block alongside
_tempSubscription, _tempTradeKey, _masterKey, and _operationInProgress so the
completer is consistently cleared after syncTradeIndex() completes or fails.
- Around line 971-1018: syncTradeIndex sets _operationInProgress = true but
never assigns _operationCompleter, so concurrent callers to initRestoreProcess
(which checks _operationInProgress and _operationCompleter) may bail out instead
of awaiting completion; fix by creating and assigning a Completer<bool> to
_operationCompleter at the start of syncTradeIndex (before async work) and
ensure you complete or completeError that completer in both the try and
catch/finally paths (use the existing finally block to complete if not already
completed), so initRestoreProcess can await _operationCompleter while
_operationInProgress is true.