Async bcryptjs measured to still not yield the event loop for realistic
hash costs (~70ms compares finish before its 100ms yield threshold), so
a login flood could still stall the same process's live MegaPay payment
webhooks. Caps each client (or shared-proxy-bucket, see known limitation
below) to 5 POST /admin/login attempts per rolling 60s window via
express-rate-limit; requests over the limit get a 429 with a Vietnamese
error and never reach adminAuth.login, so the bcrypt compare never runs.

Known limitation: this app has no app.set('trust proxy', ...) configured
and runs behind a reverse proxy in production, so express-rate-limit's
default req.ip-based bucketing will key off the proxy's address, not the
real client IP. In production this enforces "5 attempts/minute in
aggregate behind the proxy" rather than "5 per real client IP" — an
accepted trade-off for this low-traffic internal tool, but not the same
guarantee trust proxy + per-IP limiting would give. Configuring trust
proxy is an infrastructure change, left out of scope here.