feat(session): add login() that attaches the user through the middleware

[allen0099]

What

Adds login(request, user) to fastapi_cachex.session: the supported way to log a user in under FastAPICacheXSessionMiddleware so that require_user_session / AuthenticatedSession accept the next request.

• Anonymous loaded session (e.g. a cart): the user is attached, then the ID is rotated against session fixation. The data is kept and the old token no longer resolves.
• Same user_id (a re-login): the same, and the new SessionUser replaces the stored one, so changed roles or metadata take effect.
• Another user's session: it is deleted and request.session is emptied, so neither its data nor writes made earlier in the request reach the new user (as Django's login() flushes). A new session is started, its old token no longer resolves, and writes after login() are saved as usual.
• No session loaded (a new visitor, or a token that did not resolve): a new session is created with the user, with the IP / User-Agent bindings the middleware would apply.
• The middleware then sends the token through the request's transport: the response header for a header or Authorization: Bearer token, otherwise an HttpOnly Set-Cookie. The response gets Cache-Control: private, no-store, as every token-carrying response already does. Keys written to request.session before or after the call are saved into the logged-in session (earlier writes are dropped when the session was another user's).
• login() returns the session, and get_session returns it for the rest of the request.

Edge cases (documented in the docstring and the guide)

• Outside FastAPICacheXSessionMiddleware (no middleware, or the deprecated header-only SessionMiddleware, which cannot send a token for a session it did not load): RuntimeError with a message that names the middleware.
• clear() after login() in the same request is a logout: the new session is deleted and no token is sent (a cookie client gets its cookie expired).
• clear() before login(): the loaded session is logged out (deleted), and login() starts a new session instead of rotating the cleared one.
• A request with no token gets the cookie only, consistent with examples/session_login.py: the new-visitor login sends its session cookie without Cache-Control: private, no-store #322. An API client that needs the token in the body can return manager.issue_token(session) for the returned session.
• Calling login() twice rotates again and keeps the last user.

How

_RequestSession now records the backend session it belongs to and the middleware that created it. login() updates that record, and the middleware reads it when the response starts, instead of the session it loaded. The existing "session ID changed, so send a token for the new ID" path then handles both transports. The FastAPICacheXSessionMiddleware public API is unchanged.

Docs and example

• The rotate_session_id docstring and SESSION.md (EN + zh-TW) now document login() as the way to log in. They state plainly that request.session["user_id"] is application data, not a login. rotate_session_id stays documented for rotating without a login.
• examples/session_login.py uses login(). It no longer builds the cookie by hand, calls update_session() or sets Cache-Control itself. test_session_login_response_is_private still passes, since the middleware sets the header.
• Changelog fragment changelog.d/293.added.md.

Tests

tests/session/test_login.py:

• new visitor → login → AuthenticatedSession route, for cookie, header and Bearer;
• switching users (cookie and header): the old token no longer resolves and the new session holds none of the previous user's data; a re-login with the same user_id keeps the data and updates the user; an anonymous login keeps writes made before login();
• an anonymous session keeps its data under a new ID, and the old token is rejected (each transport);
• writes before and after login(), login() then clear() (cookie and header), clear() then login(), login twice, IP / User-Agent binding;
• RuntimeError outside the middleware and under the deprecated SessionMiddleware.

The key tests were mutation-checked: each targeted mutation of the implementation made at least one of them fail.

Closes #293