isFloat builds a literal undefined separator for an unknown locale #2862

Describe the bug

isFloat interpolates the locale separator straight into a new regex:

const float = new RegExp(`^(?:[-+])?(?:[0-9]+)?(?:\\${options.locale ? decimal[options.locale] : '.'}[0-9]*)?...`);

When options.locale is not a key of decimal, the lookup yields undefined,
which stringifies into the pattern as the literal text undefined. The
preceding \\ produces \undefined, and since \u is not followed by four hex
digits the escape degrades to a literal u in non-unicode mode. The compiled
separator is therefore the eight-character string undefined.

There is no error and no fallback to ., so an unrecognized locale silently
produces a validator that accepts nonsense and rejects ordinary decimals.

Examples

const validator = require('validator'); // 13.15.35

validator.isFloat('3undefined5', { locale: 'no-such' }); // true
validator.isFloat('3.5',         { locale: 'no-such' }); // false

// Plausible tags that are simply not in the table behave the same way
validator.isFloat('3undefined5', { locale: 'de-CH' });   // true

de-CH is the case most likely to reach production: it is a real BCP 47 tag
and a reasonable thing to pass, but it is not among the sixty-eight keys in
decimal, so any Swiss German user silently gets the broken validator.

Reproductions

The Examples block above runs as-is on Node after
npm install [email protected]; no harness or scaffolding needed.

Additional context

Other locale-aware validators reject an unknown locale with
throw new Error('Invalid locale ...'). Matching that here, or falling back to
., would both be an improvement over building an unusable pattern.

Validator.js version: 13.15.35
Node.js version: v26.7.0
OS platform: Linux