Use constant-time comparison when validating server certificate fingerprint token

validateFingerPrint() compared the locally-computed validation hash against the server-provided value using a plain string equality (hashHex === serverValidationHex).

The validation token is derived from the user's hashed password, the handshake seed, and the TLS certificate fingerprint. JavaScript string === short-circuits on the first differing character, so the time taken before the connection proceeds or aborts leaks the matching-prefix length of this secret-derived token.

A man-in-the-middle can fix the handshake seed and present its own certificate fingerprint consistently across reconnects, then recover the token byte by byte through timing observation and replay it to pass the anti-MitM fingerprint check — without ever knowing the password. This defeats the protection added in CONJS-349.

Fix:

Replace the short-circuiting === comparison with a constant-time comparison via crypto.timingSafeEqual. Because timingSafeEqual requires equal-length buffers (it throws otherwise), a length check is performed first; this only compares the non-secret encoded length and does not reintroduce a timing leak.