fix(4.5.2): skip accounts already configured with nologin/false shell

[Buanderie]

Problem

The 4.5.2 task iterates all system accounts (UID < UID_MIN) and
unconditionally calls ansible.builtin.user to set shell and lock them,
even when those accounts are already fully compliant.

This produces false positives: every
system account already set to /sbin/nologin is reported as "would
change", inflating the non-compliance count and making the remediation
appear non-idempotent.

A common trigger is Debian/Ubuntu service accounts whose home is
/nonexistent — they ship with /sbin/nologin already, yet are
constantly flagged.

Root cause

The CIS 4.5.2 benchmark definition targets only accounts that still
have a valid login shell. The reference audit script (e.g. Tenable
CIS_Debian_Linux_10_v2.0.0 audit id da60f23f) uses:

l_valid_shells="^($( awk -F\/ '$NF != "nologin" {print}' /etc/shells |
... ))$"
# only flags: uid < UID_MIN AND shell ~ l_valid_shells

Accounts already on nologin / false are explicitly out of scope.

Fix

Add item.shell not in ['/sbin/nologin', '/usr/sbin/nologin',
'/bin/false']
to the when guard of both subtasks. This requires switching from
with_items + map(attribute='id') to loop over the full object so
that item.shell is accessible.

Effect

• No behaviour change on non-compliant systems (accounts with a valid
  login shell are still remediated).
• Audit (--check) mode no longer reports already-compliant accounts
  as drifted.
• Remediation becomes truly idempotent: running the playbook twice
  produces changed=0 on the second run.

[github-actions]

Congrats on opening your first pull request and thank you for taking the time to help improve Ansible-Lockdown!
Please join in the conversation happening on the Discord Server as well.