Wallet state is inconsistent after modification if wallet save fails

Following on #1386

When modifying a wallet, the final save can fail if the wallet file does not have write permissions [e.g. if the file is "hidden" on windows]. This leaves the internal wallet in an inconsistent state, since the internal wallet will have the new changes but the saved wallet does not.

Rollback functionality could be difficult and bug prone, but investigate if it is possible (by working with copies of *Wallet and delaying the service.Wallets update).

If rollback functionality is not simple, another option is to test if the wallet file is writeable before performing the operation.

Start by tracing wallet modification through the final save, using issue #1386 for context, and reproduce the failure with a wallet file that is not writable. Determine whether the in-memory and saved wallets remain consistent after the save fails; done means the operation safely rolls back or rejects the change before modifying state.

Written by the indexing model from the issue text.