Ok, so as always, after a few days of working on this problem, all it took was for me to write it down in StackOverflow and a new idea came to my mind.

After trying everything in Keystonejs documentation, I just started debugging their source code and it appears there is an undocumented authentication feature with the standard header:

authorization: Bearer + <token>

As luck would have it, I had just developed a custom bearer authentication for a different mechanism but I had no idea that keystone was checking for something in that header.

Not only looking into it, but if a bearer is present, the session cookie is ignored:

const token = bearer || cookies[cookieName];

( from node_modules/@keystone-6/core/session/dist/keystone-6-core-session.cjs.dev.js)

 async get({
   context
 }) {
  var _context$req$headers$;
  if (!(context !== null && context !== void 0 && context.req)) return;
  const cookies = cookie__namespace.parse(context.req.headers.cookie || '');
  const bearer = (_context$req$headers$ = context.req.headers.authorization) === null || _context$req$headers$ === void 0 ? void 0 : _context$req$headers$.replace('Bearer ', '');
  const token = bearer || cookies[cookieName];
  if (!token) return;
  try {
    return await Iron__default["default"].unseal(token, secret, ironOptions);
  } catch (err) { }
},

So, the moral of the story is: never use a Bearer token if a session cookie is present, or at least do not do so if you are using Keystonejs