The number lexer only consumed a float's decimal point when the next character was not another dot, a misguided guard meant to handle `1..toString()`. But `1.` is itself a valid numeric literal (= 1.0): in `131..toString()` the first dot is the decimal point of `131.` and the second is the member operator. With the guard, `131` was tokenized and the parser then choked on the leading `..` ("expected identifier name, found Dot"). A number is never the start of a `...` spread, so the decimal point can always be consumed. Surfaced while investigating tradera.com (isu issue 344): its prebid.js bundle contains `${131..toString()}`, which failed to parse. Also filed isu issue 357 for a separate "CreateClosure: upvalue register does not hold a cell" VM error surfaced on the same page. Tests: crates/js/tests/number_member_access.rs and a lexer unit test test_number_dot_member. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>