macOS plugin ACL parser trusts display names as UID identity #6017

Summary

Merged PR #6012 relaxed macOS ACL handling but macAclListingTrustError treats the literal resolved principal name user:0 as root. macOS /bin/ls -lebd prints user:<directory-record-name> for resolved ACL identities; that text is not numeric UID evidence. A non-root record named 0 is therefore accepted as though it were UID 0.

Security boundary

Local plugins are dynamically imported before server bind and run in the proxy process with the operator's credentials. The loader's invariant is that only the checked path owner, the current process user, or actual root may have effective write authority on a plugin file/directory/ancestor. A foreign effective writer must make the path untrusted.

Current path:

1. aclTrustError executes /bin/ls -lebd -- <path> on macOS.
2. macAclListingTrustError parses an effective allow ACE.
3. [owner, currentUser, "root", "0"] accepts user:0 without binding it to UID 0.
4. loadOcxPlugins subsequently imports the accepted file with operator credentials.

A recorded listing with an operator-owned mode-0600 plugin and user:0 allow write currently returns null (trusted). user:runner and user:root are legitimate controls and must remain trusted; foreign read-only and deny-only entries must remain accepted under #6012's intended policy.

Required fix

Remove the numeric-looking record-name exception, or bind the ACL identity to verified UID/UUID identity before granting root trust. Add a regression that distinguishes user:0 allow write from user:root, owner/current-user grants, harmless read-only entries, and group/bare principals.

This is a follow-up to a changes-requested review that remained unresolved when #6012 was merged as 2a3cfa5abe.