the acl check could not fail, because sudo drops DATA_PATH

Review of 76cd7c2. The ACL finding is right and the fix is correct — verified here that `setfacl -R -P -b`
removes the default entries as well as the access ones, which the man page splits between -b and -k and
does not settle. `acl` is already a core package in setup.sh, so the new hard dependency is real.

But the checker it added cannot fail in the way it is documented to be run.

`assert-uid-free.sh` is invoked as `sudo ./assert-uid-free.sh --check ...`, and sudo's env_reset DROPS
DATA_PATH, so the script falls back to the hardcoded `/home/pastilhas/officerdev/data` — which is not this
machine's data directory and does not exist. Every check in the file is "look for X, report ok when nothing
is found", so a missing root reports clean without looking. Demonstrated: a tree carrying both
`user:65534:rwx` and `default:user:65534:rwx` was reported as `ok  no ACL entries naming uid 65534`.

The ACL check is the one that fails silently and completely, because it is the only one scoped to DATA_PATH
alone — the uid and subuid scans still walk /home and would catch something. So the check just added to
catch the hazard ownership cannot see is the check a wrong DATA_PATH disables.

Fixed by refusing rather than passing:

  require_roots       every search root must exist, or exit 2 naming it and showing the sudo invocation
                      that preserves DATA_PATH
  numeric guard       uid/start/count must be numbers. deprovisionOsAccount logs '<no-subuid-range>' in
                      that position for an account with no /etc/subuid entry, and pasting that log line in
                      — which is exactly how it is meant to be used — made sub_end empty and turned the
                      range scan into a no-op.

The handler's audit line now prints DATA_PATH inside the command it tells the operator to copy, and says
so explicitly when there is no subuid range rather than emitting a command that cannot work.

Verified: bogus root exits 2, non-numeric range exits 2, and the ACL check FAILS on a specimen tree
carrying the entries — the "make it fail before trusting it to pass" step from the spec's own subuid
section, now done for the ACL half too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/deprovision-os-account.md

@@ -174,9 +174,15 @@ implementation calls is a restatement of its own beliefs, not an audit. Two mode
 
 ```
 ./scripts/assert-uid-free.sh --capture green                    # BEFORE: prints "green 1001 165536 65536"
-sudo ./scripts/assert-uid-free.sh --check green 1001 165536 65536   # AFTER: exit 1 unless clean
+sudo DATA_PATH="$DATA_PATH" ./scripts/assert-uid-free.sh --check green 1001 165536 65536   # AFTER: exit 1 unless clean
 ```
 
+**Pass `DATA_PATH` through explicitly.** sudo's `env_reset` drops it, so the plain `sudo ./assert-uid-free.sh`
+this used to say fell back to a hardcoded default — and every check here reports `ok` on finding nothing, so
+a wrong root reports `CLEAN — uid safe to reissue` without having looked at a single member tree. The ACL
+check is the one that failed silently and completely, because it is the only one scoped to `DATA_PATH` alone.
+The script now refuses to run when a search root is missing rather than passing vacuously.
+
 The range has to be captured **before** deletion, because `userdel` removes the `/etc/subuid` entry with the
 account. After that there is no way to ask what range it held — and a check that silently skips that half is
 the exact failure this section exists to prevent.
@@ -293,7 +299,7 @@ To validate on the production host, against a throwaway account:
 4. Confirm the range check *fails* on that tree while the account still exists. A checker that has never
    failed has not been tested.
 5. Delete through the UI, then
-   `sudo ./scripts/assert-uid-free.sh --check <user> <uid> <start> <count>`.
+   `sudo DATA_PATH="$DATA_PATH" ./scripts/assert-uid-free.sh --check <user> <uid> <start> <count>`.
 
 The delete handler logs that exact command line with the captured values after a successful deprovision,
 because after `userdel` nothing else on the machine remembers the range.