Admin-set additional emails are never auto-verified

Describe the bug
Two distinct bugs in UsersController.php prevent additional emails set by an admin via the Provisioning API from being automatically verified.

Technical Details
This isn't an area of code I'm too familiar with; I don't have time to address this fully at the moment, so I'm leaving the details here:

1. editUserMultiValue() line 859: getPropertyByValue($key) incorrectly looks up the old email (just removed) instead of the new $value. This always returns null, causing the code to skip setLocallyVerified(VERIFIED).
2. editUser() lines 1130–1145: The COLLECTION_EMAIL case contains no auto-verify logic at all.

The $key / $value variable naming is somewhat confusing in this area of code, so these logic gaps weren't immediately obvious.

Impact
Admin-provisioned additional emails remain in a "not confirmed" state, which:

• Blocks them from being set as the primary email.
• Prevents their use for password resets and system notifications.
• Triggers unnecessary verification emails to the end user.

Expected behavior
Additional emails set by an administrator via the API should be marked as verified automatically.

Additional context
These bugs have likely gone unnoticed because the standard Admin UI does not expose additional email management for other users; the issue is currently limited to direct callers of the Provisioning API.

Start in UsersController.php at editUserMultiValue() around line 859 and editUser() around lines 1130–1145. Trace how the Provisioning API updates additional emails and how local verification is assigned, paying attention to the $key/$value roles. Done means administrator-set additional emails are automatically marked verified in both code paths and existing behavior remains intact.