The scenario I was attempting to leave open here is in the single-user case, where an org admin previously configured passcodes on, but then decided to turn them off.

As for the call only being made based on a policy determination, I disagree; `SFSecurityLockout` is responsible for passcode policy determinations.  That responsibility shouldn't bleed into a passcode consumer.  The rest of the functionality updates in this PR have actually tried to more explicitly consolidate that responsibility into this class.

This case will be triggered when one user logs in with a passcode, and switches to an org/user without a passcode.  As currently implemented, we'll simply go with the previously configured master settings.