Verify the epoch-expiry fix on Kali template 902 (ifrit) when it is next built #1196

Summary

Template 902 (tpl-kali, ifrit's Kali) is built from the same packer/kali.pkr.hcl + packer/kali/preseed.cfg.pkrtpl as 910. 910 shipped its service accounts with shadow account-expiry pinned to the epoch, so clones booted degraded (lightdm's user@<uid>.service fails PAM). Fixed for both templates in the shared preseed by #1194 / PR #1195 (merged a953afc), and verified on a fresh 910 rebuild+clone (running, 0 failed units, 0 epoch-expired accounts).

902 was not verified: it lives on ifrit (not Saruman), has no running clone, its build is blocked by #790, and there's no libguestfs on Saruman for an offline disk read. It will keep the defect until it's rebuilt from the fixed preseed.

What to do

When 902 is next built on ifrit (part of #790), confirm the fix carried:

# on a fresh 902 clone:
getent shadow | awk -F: '$8==1 {print $1}'   # expect NO output (0 accounts at epoch)
systemctl is-system-running                   # expect: running  (not degraded)
systemctl --failed                            # expect: 0 loaded units listed

The late_command step added in PR #1195 clears exactly the epoch-expired accounts, so a fresh 902 build should come up running. If 902 is built before that branch merged into whatever ifrit builds from, re-point it at current main first.

Context

• Fix: Kali template ships service accounts expired at the epoch → every clone boots 'degraded' (user@968/lightdm PAM) #1194 (closed), PR fix(packer): clear epoch account-expiry on Kali service accounts so clones don't boot degraded #1195 (merged a953afc).
• Found on garuda (910's clone) during A Kali Purple analyst workstation (garuda) on Saruman, not a second SOC #921 §9; garuda itself was fixed live.
• 902 ownership / build: Build tpl-kali (VMID 902) on ifrit once it exists #790, ADR-0091 (902 stays ifrit's, 910 is Saruman's).