feat: add conditional auth actions

[memleakd]

Description

This PR adds a small opt-in way for auth actions to decide whether they apply to a specific user.

The idea came from the earlier MFA/2FA discussions and stalled work around Shield.

• feat: add allow to cancel actions for custom cases #324
• 2FA for Specific User Group(s) #1120
• feat: expand 2FA support #1254

This is the first small piece: actions can implement ConditionalActionInterface and return true or false from appliesTo(User $user). That makes cases like "require an action only for admins" possible without changing existing actions or forcing every app into the same policy.

final class AdminEmail2FA extends Email2FA implements ConditionalActionInterface
{
    public function appliesTo(User $user): bool
    {
        return $user->inGroup('admin', 'superadmin');
    }
}

Existing actions keep working as before. If an action does not implement the new interface, Shield treats it as always applicable.

A couple of edge cases are handled intentionally:

• If a conditional action does not apply, Shield skips starting it and ignores stored identities for that action.
• If a user is already inactive and has a stored activation identity, Shield still requires activation. This avoids turning conditional activation into a way around activation.
• If an action is already pending in the session, Shield continues that pending action instead of rechecking the condition mid-flow.

This should give Shield a safer foundation for future MFA work, while keeping this PR focused on the existing auth action system.

Tests cover login actions, registration activation, stored action identities, magic-link activation, and session filter behavior.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide