Fixes some shielded component jank (#79674)

## About The Pull Request

If you attempted to use the shielded component properly (applying it in
`Init`), it would not work because the equipped signal was improperly
passing its arguments to `set_wearer`.

The only reason why this worked now is that every consumer added the
component after it was `equipped`... usually in `equipped`.

This also meant shielded items that added it in equipped were open to an
exploit, allowing you to reset the charges by unequip / re-equip.

## Changelog

🆑 Melbert
fix: Fixes some potential exploits and issues involving shielded
equipment.
/🆑

code/datums/components/shielded.dm

@@ -3,6 +3,7 @@
  */
 
 /datum/component/shielded
+	dupe_mode = COMPONENT_DUPE_UNIQUE
 	/// The person currently wearing us
 	var/mob/living/wearer
 	/// How many charges we can have max, and how many we start with
@@ -113,7 +114,7 @@
 	if((slot & ITEM_SLOT_HANDS) && !shield_inhand)
 		lost_wearer(source, user)
 		return
-	set_wearer(source, user)
+	set_wearer(user)
 
 /// Either we've been dropped or our wearer has been QDEL'd. Either way, they're no longer our problem
 /datum/component/shielded/proc/lost_wearer(datum/source, mob/user)
@@ -125,6 +126,11 @@
 		wearer = null
 
 /datum/component/shielded/proc/set_wearer(mob/user)
+	if(wearer == user)
+		return
+	if(!isnull(wearer))
+		CRASH("[type] called set_wearer with [user] but [wearer] was already the wearer!")
+
 	wearer = user
 	RegisterSignal(wearer, COMSIG_ATOM_UPDATE_OVERLAYS, PROC_REF(on_update_overlays))
 	RegisterSignal(wearer, COMSIG_QDELETING, PROC_REF(lost_wearer))