feat(admin): give the admin dashboard a way in

[MOHITKOURAV01]

Closes #125.

The defect

There was no way to sign in as an admin.

$ grep -rn "api/admin/login" frontend/src
$

POST /api/admin/login is the only issuer of a token carrying role: "admin",
and nothing in the browser called it. App.jsx declared eight routes and none
of them was /admin; Login.jsx posts to /api/user/login and nothing else.

The normal sign-in is not a way in either: validateRegistration refuses a
self-assigned role — the point of #55 — so no account created through
/register can hold type: "admin", and backend/scripts/ contains
dedupeUserEmails.js and nothing else.

Both ends were complete and neither could reach the other:

built	unreachable
adminLoginController, constant-time check, activity log entry	no caller
eight routes behind [authMiddleware, checkRole(["admin"])]	no token
AdminHome, PaymentRecords, ActivityLogs, admin AllCourses	never rendered

Calling the endpoint by hand did not help

Suppose an operator ran the request in a console and wrote the token into
storage. The session layer still refused it:

return parsed._id || parsed.id ? parsed : null;      // parseStoredUser
...
if (!user || !isTokenValid(token, nowMs)) {          // readSession
  return { isAuthenticated: false, user: null, token: null, role: '' };
}

readSession needs both a valid token and a stored user with an id. The
endpoint returned neither:

return res.status(200).send({ success: true, token, message: "Admin login successful" });

So isAuthenticated stayed false, ProtectedRoute bounced back to /login,
and getUserRole(undefined) returned '' — which would have rendered "This
account has no dashboard yet" even if the guard had let it through.

What is here

utils/adminAccount.js. The admin is not a users row; authMiddleware
recognises the reserved id without a lookup and built the identity inline. That
literal now comes from buildAdminAccount, and so does the account in the login
response, so the two cannot describe the admin differently. It carries _id for
parseStoredUser, type and role for getUserRole, and name from
ADMIN_USERNAME so the navbar says which operator account is signed in. It
carries no email — the admin is a credential pair in the environment, not an
account with a mailbox, and a fabricated address would be worse than an absent
one.

The login response carries that account under userData, the key
/api/user/login already uses.

/admin/login, in PublicOnlyRoute like /login, with a link in the
footer under Legal — it is for the operator account configured on the server,
not for learners, but it has to exist somewhere and until now it existed
nowhere. It writes the session with the same writeSession the learner sign-in
uses and calls refresh() on the auth context before navigating: AuthProvider
reads storage on mount and on the storage event, which only fires in other
tabs, so without that the redirect would arrive before the provider knew there
was a session and ProtectedRoute would bounce it straight back.

lib/adminSession.js refuses a response carrying a token with no account —
the exact shape the endpoint used to return — and refuses a non-admin role at
the form, where there is still somewhere to show a message, rather than at the
dashboard where the only outcome is a blank panel. A 500 from an unconfigured
server ("Admin access is not configured on this server") passes through
verbatim, because that sentence tells an operator to set the environment
variables instead of retyping a password that can never work.

Tests

backend/tests/admin-account.test.js — 7 tests on the account object, no
database. What it carries, what it deliberately does not, and that a fresh
object is returned each call — authMiddleware's other branch assigns to
req.user, so a shared singleton would be a cross-request mutation.

backend/tests/admin-auth.test.js — 5 tests added. The account satisfies the
browser's own parseStoredUser rule, restated on this side so the two cannot
drift, and survives the JSON round trip localStorage puts it through; the
login response and the account authMiddleware builds are compared field by
field through a probe route; a rejected sign-in carries no account; and the body
is checked for the configured password and for anything shaped like a bcrypt
hash.

These went into the existing file rather than a new one on purpose: sixteen test
files each start their own MongoMemoryServer and node --test runs them in
parallel, and a seventeenth tipped this machine into Instance failed to start within 10000ms across unrelated suites.

frontend/src/lib/adminSession.test.js — 15 tests, including the defect itself:
{ success: true, token } with no account is refused.

docs/issue-125-admin-signin.md has the write-up.

Checklist

• cd backend && npm test — 517 pass (505 on main, 12 added)
• cd frontend && npm test — 229 pass (214 on main, 15 added)
• cd frontend && npm run build
• npm run lint — does not pass on main (69 problems) and does not here.
  SiteFooter.jsx reports the same 1 before and after, a pre-existing
  unused React import. lib/adminSession.js, AdminLogin.jsx and
  App.jsx lint clean.

Notes

The credential check, its constant-time comparison, the production refusal of a
plaintext ADMIN_PASSWORD, the activity log entries, the token and every admin
route and screen are unchanged. They did not need editing; they needed reaching.

[udaycodespace]

Reviewed this, @MOHITKOURAV01 . This cleanly connects the existing admin authentication backend with the frontend without changing the underlying admin credential or authorization flow.

The shared admin account construction, session handling, /admin/login route, role validation, and auth-context refresh are all addressed properly. The tests also cover the important failure case where a token is returned without the account data.

All backend and frontend tests are passing, and the frontend build is clean.

Approved and merging.