fixes silly mistake in can_be_held element (#96960)

## About The Pull Request

Error from #96917 (cb535cdfa6)

We shouldn't be calling `mob_try_pickup` on the other pathways, that's
the responsibility of the mousedrop proc. The other two signal handling
procs on this element exist only to block storage dumping/stripping when
the mousedrop proc is working. I think I didn't catch this in testing
because it's an invisible bug that gets obfuscated by the `do_after()`
but I pretty obviously fell asleep at the wheel here and added this
extra code when it's definitely not meant to work that way.

I'm gonna do a CL because I forgot to mention something in the original
refactor's changelog so people might be more aware of the new mechanic
that I forgot to mention (implemented to better reliably parse intent
and be less ambiguous)

🆑
refactor: Picking up your pets (or any holdable mob) requires an
aggressive grab now.
/🆑

code/datums/elements/can_be_held.dm

@@ -29,21 +29,20 @@
 	INVOKE_ASYNC(source, TYPE_PROC_REF(/mob/living, mob_try_pickup), user)
 	return COMPONENT_CANCEL_MOUSEDROP_ONTO
 
+/// Blocks strip menu opening if we can reasonably assert that the mob is trying to be picked up
 /datum/element/can_be_held/proc/on_strip_menu_open(datum/source, atom/over, mob/user)
 	SIGNAL_HANDLER
 	if(!trying_to_hold_mob(user, source))
 		return
 
-	INVOKE_ASYNC(source, TYPE_PROC_REF(/mob/living, mob_try_pickup), user)
 	return COMPONENT_BLOCK_STRIP_MENU_OPEN
 
-
+/// Blocks storage dumping if we can reasonably assert that the mob is trying to be picked up
 /datum/element/can_be_held/proc/on_attempt_storage_dump(datum/source, atom/over, mob/user)
 	SIGNAL_HANDLER
 	if(!trying_to_hold_mob(user, source))
 		return
 
-	INVOKE_ASYNC(source, TYPE_PROC_REF(/mob/living, mob_try_pickup), user)
 	return CANCEL_STORAGE_DUMP