fix(client): COPY with DB 0 must emit the DB argument

[spokodev]

Description

COPY source destination { DB: 0 } silently drops the DB 0 argument, so the key is
copied to the current database instead of database 0.

The destination-db guard in packages/client/lib/commands/COPY.ts used a truthy check:

if (options?.DB) {
  parser.push('DB', options.DB.toString());
}

0 is a valid database index (the default database), but it is JS-falsy, so the DB 0
tokens were never sent. A client connected to a non-zero database that asks to copy a key
into database 0 ends up writing the copy into its current database, with no error. Per the
COPY spec, the syntax is COPY source destination [DB destination-db] [REPLACE] and
destination-db can be 0.

The fix switches to an explicit !== undefined check, matching how every other numeric
command option in the client is guarded (BITPOS, XCLAIM, RESTORE, SCAN, and others). Added
a spec case covering DB: 0; the existing suite only exercised DB: 1.

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

---

Note

Low Risk
Single-line guard change in Redis command argument parsing plus a unit test; no auth, persistence, or API surface changes beyond correct COPY behavior for database 0.

Overview
Fixes COPY so { DB: 0 } is serialized as DB 0 instead of being omitted.

The destination-database guard in COPY.ts used a truthy check on options?.DB, so index 0 (a valid Redis DB) never reached the wire and copies landed in the client’s current database. It now uses options?.DB !== undefined, consistent with other numeric options in the client.

Adds a transform test for DB: 0 alongside the existing DB: 1 case.

^{Reviewed by Cursor Bugbot for commit cd95d7d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[nkaradzhov]

Thanks @spokodev, this looks good!