Shell out to ldapsearch for the directory browse instead of ldapjs

Bisecting through attribute selection and paging kept reproducing the
same failure in different shapes ("Encoding too long" BER parser error,
then ECONNRESET) — all while a plain `ldapsearch` against the exact same
query, run from inside this same container, completed successfully every
single time. That's strong enough evidence of a bug somewhere in
ldapjs/@ldapjs-asn1's BER decoding against this AD's actual response
bytes, not in our query. Rather than keep chasing a third-party parser
bug, searchLdapDirectory() now shells out to the system `ldapsearch`
(added to the image via ldap-utils) and parses its LDIF output directly
— the same tool that's already proven reliable here. authenticateLdapUser
(the per-login lookup) is untouched: it's a narrow single-match query
that has shown no sign of this issue, and isn't worth the added latency
of spawning a process on every login.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012o9j9RezxbZVKQMrB7oRLY

Dockerfile

@@ -1,9 +1,11 @@
 FROM node:20-bookworm-slim
 
 # python3/make/g++ let npm fall back to compiling better-sqlite3/argon2 from
-# source if no prebuilt binary matches this platform.
+# source if no prebuilt binary matches this platform. ldap-utils provides
+# the `ldapsearch` binary used for the LDAP directory browse — ldapjs's own
+# BER decoder proved unreliable against real AD responses for that query.
 RUN apt-get update && apt-get install -y --no-install-recommends \
-    python3 make g++ ca-certificates \
+    python3 make g++ ca-certificates ldap-utils \
     && rm -rf /var/lib/apt/lists/*
 
 WORKDIR /app