How does SPV prevent double spending of UTXO?
In a bitcoin transaction, A's address is not scanned for spendable Unspent Transaction Outputs (UTXOs). Full nodes simply check if the inputs of the transaction are really unspent. There is no scanning of addresses involved. 

UTXOs are stored as the transaction id (txid) and the output index of the transaction that created them. You cannot reference the outputs to be spent by address, the address merely specifies which private key must sign the input script in order to claim the UTXO. 

Suppose you advertise addr1 for donations, and you receive 3 donations D1,D2 and D3 on that address. You have 3 UTXOs and not 1. The only thing is that they can be claimed by same private key. Hence, there is no looking around for previous transactions. Wallet has to specify which UTXOs it is consuming.

SPV allows a lightweight client to verify that a transaction is included in the Bitcoin blockchain, without downloading the entire blockchain. To verify that a transaction is in a block, a SPV client requests a proof of inclusion, in the form of a Merkle tree branch. It does not check for double-spend on it's own. Rather it relies on the full node servers it is connected to do so. To prevent from being cheated from single server, they connect to multiple servers to get the block headers.
From Bitcoin Wiki:


  The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack. 


You might also want to look into Fraud Proofs which would allow full nodes to prove that information propagated on the network is invalid, e.g. allow full nodes to point out double-spends to thin clients. 

Another Reference: Thin Client Security