newusers: create or update accounts in batch

[pierre-warnier]

Adds newusers, the eighteenth tool: one line of seven fields becomes a whole account.

Stacked on #292. Base retargets to main as the stack merges.

For each line it writes the /etc/passwd record, the hashed /etc/shadow record, a group where one is needed, and the home directory with /etc/skel copied in.

All or nothing

Every line is parsed, every name validated, every group resolved and every password hashed before anything is written. A batch with one bad line leaves the system exactly as it was, including for the good lines above it.

The failure mode is nothing happened, not the first two hundred accounts exist and the rest do not. That is the whole reason to reach for this tool instead of a shell loop around useradd.

Home creation is now shared, not copied

useradd's version forces the umask so the requested mode is exact, and hands ownership over through a descriptor opened O_NOFOLLOW — so nobody who can write the parent can swap in a symlink between the mkdir and the chown. Copying that into a second tool is a second chance to get it wrong, silently. It moved to shadow_core::home; useradd calls it and its own tests still pass.

Deliberate divergences

All three established by running the GNU tool, not by reading it:

	GNU	here
empty password field	passed to PAM, which refuses it after creating the account	refused before anything is written
pw_gid naming a group that does not exist	falls back to the user's own ID, creates no group — the account points at a GID that is not there	refused
missing parent directory	fails, unlike GNU's own useradd -b	created, as useradd -b does

--badname is implemented rather than stubbed: it drops the portability rules on the login name but keeps the checks that stop a name from corrupting the file or being read as an option, which is what makes the flag safe to offer. That is what lets a domain-qualified name from a directory join through.

Verification

cargo test --workspace	828 passed on debian, alpine and fedora
make check	fmt, clippy ×3, tests ±pam, plus the unprivileged run — exit 0
e2e deployment suite	297 assertions against a real install
make test-gnu-compat	45 comparisons against the GNU binaries
make test-arm64	22 assertions under emulation

The e2e section re-hashes the stored field with its own salt and compares, so a tool writing a well-formed hash of the wrong string fails; the negative control — the same check against a different password — is asserted to fail. An earlier draft of that assertion ended in || true and was therefore always green, which is worth saying out loud, because it is exactly the failure mode these checks exist to catch.