Describe the bug

HGETDEL accepts any token where the literal FIELDS keyword is expected. The parser hardcodes the argument position and only validates numfields and the field count, so the syntax check for FIELDS is silently skipped. This is inconsistent with HGETEX, HSETEX, and the HEXPIRE family, which all validate the keyword via strcasecmp(..., "fields").

To reproduce

127.0.0.1:6379> HSET key field value
(integer) 1
127.0.0.1:6379> HGETDEL key persist 1 field
1) "value"
127.0.0.1:6379> HGETDEL key foobar 1 field
1) (nil)
127.0.0.1:6379> HGETDEL key "" 1 field
1) (nil)

All three HGETDEL calls succeed even though none of persist, foobar, or "" is the FIELDS keyword.

Expected behavior

A syntax error, matching the behavior of HGETEX/HSETEX/HEXPIRE when FIELDS is missing or misspelled:

(error) ERR syntax error

Additional information

Source: src/t_hash.c, hgetdelCommand (~line 1158):

void hgetdelCommand(client *c) {
    /* argv: [0]=HGETDEL, [1]=key, [2]=FIELDS, [3]=numfields, [4...]=fields */
    int fields_index = 4;
    ...
    if (getLongLongFromObjectOrReply(c, c->argv[fields_index - 1], &num_fields, NULL) != C_OK) return;

argv[2] is never inspected. Compare with hgetexCommand (~line 1644), which validates the keyword:

for (; fields_index < c->argc - 1; fields_index++) {
    if (!strcasecmp(objectGetVal(c->argv[fields_index]), "fields")) {
        ...
    }
}

The command JSON spec (src/commands/hgetdel.json) declares "token": "FIELDS" on the fields block, so the literal keyword is part of the documented syntax.

Suggested fix: add a strcasecmp(c->argv[2]->ptr, "FIELDS") check before parsing numfields, returning a syntax error otherwise. HGETDEL has no optional tokens before FIELDS, so a minimal positional check is sufficient.

Affected versions: unstable HGETDEL is since: 9.1.0 per the command JSON.