fix(shared): dispatch redis TTL and Lua calls on the detected client

[ExorTek]

Stacked on #28.

The internal setWithTTL helper tried the ioredis argument form and fell back only if it threw:

try   { await client.set(key, value, 'PX', px); }
catch { await client.set(key, value, { PX: px }); }

node-redis does not throw on that call. It accepts it, ignores the trailing arguments, and stores the key with no expiry — so the fallback never ran and the TTL was silently dropped.

Measured against a real server:

authorization code saved with a 60s TTL
  ioredis     PTTL = 60000
  node-redis  PTTL = -1      (never expires)

Everything written through this helper lost its lifetime on node-redis: OAuth 2 authorization codes, PAR request URIs, device codes, opaque entries. This is the quietest defect in the set — nothing throws, nothing logs.

incr-store had the same problem in its eval call, where it at least failed loudly because Redis rejects a script invoked with no keys.

Changes

• detectDialect and evalScript added to the shared redis helpers, so there is one answer to which convention a client wants.
• Both call sites routed through it.
• incr reports driver failures through the binding package's wrap, so callers get their own error class and a code instead of a bare driver reply.
• Fake clients in the unit suites now declare which driver they imitate, and the shared suite asserts both argument forms rather than one.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.