authenticate plugin hook not invoked for /admin-auth/ endpoint, leading to ep_hash_auth not working

Description

Etherpad doesn't seem to call the authenticate plugin hook when users attempt to log in to the admin panel via /admin-auth/. This makes it impossible for authentication plugins (I tested with ep_hash_auth, but presumably any plugin relying on this hook) to handle admin logins.

Steps to reproduce

1. Install ep_hash_auth on Etherpad 3.3.2 and configure it with a hash_dir and valid bcrypt .hash files
2. Add a user to the users block in settings.json with is_admin: true but no password field
3. Attempt to log in to https://your-instance.url/admin
4. Observe 401, with nothing logged by ep_hash_auth

Expected behavior Logging in as an admin user whose password is stored on the server as a hash should be possible with ep_hash_auth installed and correctly configured.

Server (please complete the following information):

• Etherpad version: 3.3.2
• OS: Debian 13
• Node.js version: 24.18.0
• npm version: 11.16.0
• Is the server free of plugins: No
• Are you using any abstraction IE docker? No

Desktop (please complete the following information):

• OS: Linux Mint
• Browser Tested on Firefox and Chromium
• Version 22.1

Additional context / investigation The /admin-auth/ endpoint is defined in src/node/hooks/express/openapi-admin.ts as a built-in Express endpoint (verifyAdminAccess) that handles Authorization: Basic headers internally and returns 200/401/403 directly, before the plugin hook system gets involved. As a result, admin authentication seems to be hardwired to check settings.users[username].password in settings.json and I'm not sure whether plugins cannot intercept or override it.

This means that the only way to protect the admin panel (afaik) is a plaintext password in settings.json. This constitutes a regression for installations that use ep_hash_auth specifically to avoid keeping plaintext passwords on disk.

Adding console.log statements directly to ep_hash_auth's authenticate function produced no output when admin login was attempted, despite the browser correctly sending Authorization: Basic <base64> (confirmed via browser dev tools network tab). The hook is registered correctly per ep.json and fires for pad-level authentication; the issue seems to be specific to /admin-auth/.

ep_hash_auth v11.0.24 was tested. The expressCreateServer hook registered by ep_hash_auth only handles logout and does not provide an alternative interception path. There is no version of ep_hash_auth that I'm aware of that can work around this, so any fix would have to come from Etherpad core.

A plaintext password field in settings.json does work for admin authentication, confirming that Etherpad's internal handler reads credentials directly from settings.json.