fix: accept numbers written with their usual separators (se, cl, uy)

[gaoflow]

clean() in four modules doesn't normalise the input to the shape validate()'s length check expects, so each rejects the identifier as it is normally written.

se/personnummer requires the separator, so the bare 10- and 12-digit forms are InvalidLength — though format() has always accepted them:

validate('880320-0016')  -> OK            // already in the tests
validate('8803200016')   -> InvalidLength
validate('198803200016') -> InvalidLength
format('8803200016')     -> '880320-0016'

Per Folkbokföringslagen (1991:481) §18 the number contains "födelsetid, födelsenummer och kontrollsiffra" — the hyphen is written between them (and becomes + the year someone turns 100), so it isn't part of the number. python-stdnum's se.personnummer.compact() inserts the default - at those two lengths; that step wasn't ported. Finishes #97 on the validate() side.

cl/rut, uy/cedula, uy/nie don't strip the . their own format() emits, so validate(format('125319092')), validate(format('12345672')) and validate(format('912345670')) are all InvalidLength.

These are the only four: I checked all 198 modules by re-running every valid example in the specs through python-stdnum in 8 written forms, by validate(format(x))/validate(compact(x)), and by feeding python-stdnum's canonical format() back in. All three probes are empty afterwards. Where the port is deliberately ahead of python-stdnum I left it — tw/ubn (#159) and samordningsnummer, which upstream still rejects.

Tests reuse existing fixtures with only the separator changed, plus a bad check digit in each new form. npm test 1627 pass (+17); the mx/curp failure is pre-existing on main.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[gaoflow]

Thanks for the review. The branch is ready to merge.