chore: allow @adonisjs/redis v11 in peer dependencies

[DavideCarvalho]

What

Widens the @adonisjs/redis peer dependency range to also accept v11:

-"@adonisjs/redis": "^10.0.0-next.2 || ^10.0.0",
+"@adonisjs/redis": "^10.0.0-next.2 || ^10.0.0 || ^11.0.0",

Today apps that have moved to @adonisjs/redis@11 can't install @adonisjs/session without a package manager override, even though the two work together fine.

No source changes. The second commit adds CI coverage so that both ends of the declared range are actually exercised (see CI coverage below).

Why no code change is needed

@adonisjs/redis@11 is a major only because it upgrades ioredis ^5 → ^6 and raises engines.node to >=24. The release notes call out that "packages that consume ioConnection must be on the same ioredis major".

Session does not consume ioConnection, and does not import from ioredis at all (neither types nor runtime). The complete redis surface it touches is:

• src/stores/redis.ts — import type { Connection } from '@adonisjs/redis/types'
• src/types.ts — import { type RedisConnections } from '@adonisjs/redis/types'
• src/define_config.ts — /// <reference types="@adonisjs/redis/redis_provider" /> and app.container.make('redis') → .connection(name)

…and these methods on the Connection wrapper: get, setex, del, expire, sadd, srem, smembers, and pipeline() → pipeline.get() / pipeline.exec().

ioredis 5 → 6 impact on those symbols

The two behaviours worth checking are the RESP3 default (v6 negotiates RESP3 unless protocol: 2 is set) and the pipeline.exec() result shape, since RedisStore#fetchSessionContents reads result[1].

Verified against a real server with @adonisjs/redis@11.0.0 / ioredis@6.0.0, with RESP3 confirmed active (ioConnection.options.protocol === 3):

call	result
smembers	Array (not a JS Set) — ["a","b"]
get	string / null
pipeline().exec()	[[null,"v1"],[null,null]] — [error, result] tuples unchanged
expire / srem / del / sadd	integers
setex	ok

So every shape the redis store relies on is unchanged.

The engines.node: >=24 bump in redis v11 is a no-op here: @adonisjs/session already declares "engines": { "node": ">=24.0.0" }, and ioredis 6 itself only requires Node >= 20.

CI coverage

A peer range that CI never exercises is just a claim, so test_linux now runs against both majors via a new matrix dimension:

       matrix:
         node-version: [latest]
         db: [sqlite, postgres, mysql]
+        redis-version: [10, 11]

       - name: Install
         run: npm install
+      - name: Install @adonisjs/redis v${{ matrix.redis-version }}
+        run: npm install --no-save @adonisjs/redis@${{ matrix.redis-version }}

• devDependencies stays at ^10.0.0, so the default local/dev experience is unchanged and the lower bound keeps its coverage; the extra leg installs the upper bound with --no-save, so neither package.json nor package-lock.json is touched by the step.
• The step runs on both legs (not just v11) so each job states which major it ran, rather than one leg silently depending on whatever ^10.0.0 resolves to.
• test_windows is untouched — it already runs with NO_REDIS: true.

This takes test_linux from 3 to 6 jobs. If you'd rather not double the matrix, I'm happy to collapse it to a single extra leg with include (e.g. db: sqlite + redis-version: 11) — just say the word.

How it was tested

Both majors were run locally against a real Redis server before pushing:

• Node.js v24.20.0, Redis server 8.10.1 (redis:alpine, per compose.yml), DB_CONNECTION=sqlite, NO_REDIS unset so the redis store tests really execute
• @adonisjs/redis@10.0.2 → 208 passed, 14 skipped (222)
• @adonisjs/redis@11.0.0 (pulling ioredis@6.0.0) → 208 passed, 14 skipped (222) — identical; the 14 skips are the DynamoDB specs, which I have no local endpoint for (they run in CI)
• tests/stores/redis_store.spec.ts → 19 passed on both, including the tagged / untag tests that exercise smembers, srem and the pipeline path
• tests/concurrent_session.spec.ts → 9 passed on both
• npm run typecheck → clean on v11 (i.e. the Connection / RedisConnections types from v11 still satisfy the store)
• npm run lint → clean

[thetutlage]

Can you check why the tests are failing?