Stop populating user.purchases data in session cookie as it causes 431 on login #796

Root cause:

Better Auth is caching the full session user into cookies, and that user includes purchases. It happens for the user who has too many purchases.

Why QA fails:

QA cookie total: about 16.8 KB
QA __Secure-courselit.session_data.*: about 16 KB
It is split into session_data.0 through session_data.4
Decoded QA session user has 26 purchases
purchases alone is about 10.9 KB
includes SCORM/progress data too
Why prod works in your example:

Prod cookie has __Secure-courselit.session_data, but the decoded user has purchases: []
So prod’s session cookie is much smaller
This is not an apples-to-apples comparison: QA user has lots of purchase/progress state; prod user does not
Why it appears suddenly:

email-otp succeeds because the request does not yet include the newly issued huge session cookie.
email-otp response sets the large courselit.session_data.* cookies.
The next getUser /api/graph request includes those cookies.
Caddy rejects the request with 431 before Next.js/GraphQL handles it.
So the suddenness is data-size related: once a user’s cached session crosses the edge header limit, the next authenticated request starts failing. The preview PRD branch did not introduce credentials: include; it just exposed the problem during login testing.

The real bug is: auth/session cookies should not contain bulky learner progress data. They should identify the session; app data like purchases/progress should come from DB/API.