Register and login endpoints with cookie sessions

Why

Every file-related feature is scoped to a user, so auth has to exist first. We're using HTTP-only session cookies rather than JWTs: they're simpler for a browser app and the browser handles sending them.

Depends on: the SQLAlchemy/Alembic issue.

Files to touch

• backend/app/auth.py (new)
• backend/app/main.py: include the auth router
• backend/tests/test_auth.py (new)
• backend/requirements.txt: password hashing lib

Definition of done

• POST /auth/register with {email, password} hashes the password (bcrypt or argon2) and returns 201; duplicate email returns 409
• POST /auth/login verifies credentials and sets an HTTP-only session cookie; bad credentials return 401
• POST /auth/logout clears the cookie
• GET /auth/me returns the current user, or 401 if not logged in
• A get_current_user FastAPI dependency exists that later routes can reuse
• Tests cover register, duplicate email, login, and unauthorized /me

Hints

Never store plain-text passwords. passlib or argon2-cffi handle hashing. For sessions, a signed cookie (e.g. itsdangerous) is enough for now; a server-side session table can come later.

Start with the planned entry points in backend/app/auth.py and backend/app/main.py, then review the SQLAlchemy/Alembic dependency before choosing the password-hashing and signed-cookie approach. Add backend/tests/test_auth.py for registration, duplicate email, login, and unauthorized /me behavior. Done means all listed endpoints, reusable get_current_user dependency, cookie handling, status codes, and tests are present.