hardening: sanitize the process's own environment, not only children's

harden_process() clears core dumps, raises the file-size limit and applies Landlock, but leaves the process's own environment as the caller set it. In-process PAM and NSS modules therefore run with the caller's LD_*-free but otherwise arbitrary variables (PAM_*, locale, TZ, anything a module reads). Children get a clean environment where they are spawned; the tool itself does not.

docs/SECURITY-HARDENING.md lists this under Not yet implemented and pointed at #249, which was closed on 2026-09-04 without doing it.

What it would take: at the top of harden_process(), replace the environment with the sanitized set sanitized_env() already computes (PATH to a fixed value, TERM, LANG/LC_* kept), the way sudo-rs does, and drop the caller's copy. Setuid tools already ignore LD_* through the loader, so the visible change is confined to what PAM and NSS modules see. Needs a decision on which variables PAM conversations legitimately need (LANG for messages at least), and a test in the deployment suite that a variable set by the caller is not visible to a PAM module.

Start with harden_process() and sanitized_env(), then read docs/SECURITY-HARDENING.md and the sudo-rs approach referenced by the issue. Resolve which variables PAM conversations require, apply the existing sanitized set to the process environment, and add the deployment-suite test showing caller variables are not visible to a PAM module.