[Feature] Admin session auth with login page (Phase 2 of #89)

[npozs77]

Description

Phase 2 of #89 (multi-user support): Add admin session authentication with a login page and cookie-based sessions. When users.yaml defines human admin users, unauthenticated browser requests are redirected to a login page.

Builds on Phase 1 (API-key auth middleware) by extending the fallback chain: Bearer token → session cookie → deny/redirect.

Use Case

The VocabGen owner (admin) wants to protect the web UI so that only they can access config, database management, and lookups when the server is exposed on a network (e.g., via reverse proxy for classmates).

Scope

• Cookie session management (server-side sessions or signed cookies)
• Login page template (login.html) + POST /login handler
• Admin role in users.yaml (username + bcrypt password hash)
• Middleware extension: session cookie validation as second auth tier
• Logout endpoint (POST /logout)
• Session expiry and server-restart behavior

Acceptance Criteria

• WHEN users.yaml defines admin users, THE server SHALL require authentication for all non-health endpoints
• WHEN an unauthenticated browser request arrives, THE server SHALL redirect to /login
• WHEN valid admin credentials are submitted, THE server SHALL create a session and redirect to /
• WHEN a session expires or is invalid, THE server SHALL redirect to /login

Target Release

v1.5.1

Parent Issue

Part of #89 (Multi-user support with role-based profile access)
Phase 2 of 3: API-key → Session auth → Full RBAC

Dependencies

• Depends on Phase 1 sub-issue (API-key auth middleware foundation)