fix: apply the user-level settings for every human account, not just one

[catinspace-au]

A box with more than one person on it only ever got the dotfiles for whoever was named. Everyone else got the system-wide half and nothing else -- no shell config, no ~/.cargo, no ~/.local/bin, no dconf, no container stacks -- and the run reported success either way. A desktop image with a provisioning account plus a real user is exactly that shape.

install.sh now discovers the accounts and runs one pass per user.

Who gets it

Skipped by default:

• root
• system accounts -- uid below 1000, the systemd range above 60000, shells of nologin/false/sync
• the cloud image's own account, which exists to provision the machine rather than to work in

That last one is read from system_info.default_user.name in /etc/cloud/cloud.cfg rather than matched by name, because it is ubuntu on an Ubuntu image and cloud-user on a Red Hat one. --users a,b names any set instead, that account included.

Why the loop is outside the roles

There are roughly 350 user-scoped references across 49 files. A per-task loop, or a user-scope tag applied to each of them, would eventually miss one silently -- which is the failure mode this area already has a history of. Looping the invocation cannot miss a task by construction, and the system-wide tasks are idempotent, so later passes no-op on everything except that user's own files.

The playbook is unchanged and still takes one hyperi_target_user per run, so nothing about tag semantics moved. Anything driving ansible-playbook directly writes its own loop, which the docs now show.

Verified

On a real two-account host, with both accounts seeded to a 12h clock:

• pass for hyperi -> hyperi moves to 24h
• pass for ubuntu -> ubuntu moves to 24h, and hyperi is still 24h

so a later pass does not undo an earlier one. Discovery returns hyperi on one box and derek on the other, correctly excluding ubuntu in both cases. tools/ci/run-tests.sh green, shellcheck clean.