fix: parse JSON cookies with falsy values

[spokodev]

JSONCookies() only writes the parsed value back when it is truthy (if (val)), so a cookie whose JSON payload is false, 0, null or "" is left as the raw j:-prefixed string instead of being inflated. The README states such values "will be exposed as the result of JSON.parse".

JSONCookie() already returns undefined only on parse failure, so guarding on val !== undefined preserves the "keep the original value on invalid JSON" behaviour while correctly parsing falsy values.

Refs #168.

[kilisamemarisaaa]

[P1] Preserve the invalid-signature sentinel for signed JSON false. The middleware runs JSONCookies() over req.signedCookies after verification (lines 64–65), while signedCookie() and the README use boolean false to signal a failed signature. With this condition, a correctly signed j:false payload is also converted to boolean false. I reproduced both a valid cookie created with cookie-signature.sign('j:false', secret) and the same cookie with a corrupted signature; req.signedCookies.flag is false in both cases, so callers can no longer distinguish authentic data from signature failure—the exact ambiguity raised in issue #168. Please resolve that representation/API conflict before parsing false here, and add a middleware-level test covering valid j:false versus a tampered signed cookie.

[spokodev]

Reproduced, and you were right — the PR as it stood introduced that ambiguity rather than inheriting it.

On master, an authentic j:false and a tampered cookie are distinguishable, because JSONCookies skipped every falsy parse:

authentic j:false  -> "j:false"  (string)
tampered signature -> false      (boolean)

With if (val !== undefined) both became boolean false, so req.signedCookies.flag could no longer tell the two apart. That is exactly #168, and turning an open representation question into a silent one in the verification path is not a trade worth making for this fix.

So the parse is now scoped to the falsy values that have no conflict — j:0, j:"" and j:null — and boolean false is left reserved for the signature marker, with j:false staying as its raw string until #168 settles what the marker should be. The condition carries a comment saying why, so it does not read as an oversight.

Added the middleware-level tests you asked for: an authentic j:false returns {"flag":"j:false"} and a tampered one returns {"flag":false}. The first fails against the previous commit. 37 passing, eslint clean.

If the maintainers would rather resolve #168 first — say, by marking failures with undefined or a symbol — then j:false can be parsed here too, and I will extend this.