fix(optimizer): handle more chars that will be sanitized

[sapphi-red]

Since $ is also sanitized by Rolldown by sanitizeFileName, the filename does not contain $.
#21886 fixed a similar issue for +, but it was not a general fix. In this PR, I've rewritten the flattenId function to escape any characters that will be escaped by the default sanitizeFileName.

close #22198

[sapphi-red]

The sourcemap changes are caused by the optimized filename change.

[afurm]

The approach of aligning flattenId with sanitizeFileName is the right direction — handling a class of invalid path chars instead of enumerate-and-replace is more maintainable.

One concern: flattenId escapes _ to __ before calling sanitizeFileName, but then sanitizeFileName decodes __2f → _ and __2b → +. This means a dependency ID that legitimately contains the substring _2f (e.g. my_2f_lib) would after pre-bundling produce the same flattened ID as my/lib. Does sanitizeFileName have a mechanism to avoid this ambiguity, or is there an ordering issue where flattenId needs to run after sanitizeFileName rather than before?

[bluwy]

I checked and I think this should invalidate the metadata hash so it's reoptimized on Vite update. Otherwise it might still refer to the old paths.

[bluwy]

The _2f pattern here makes it harder to read personally. I understand making it robust, but maybe we can go with a middleground:

What if we do the normal underscore replacements for the commons chars, like / and ., and then do the _2f pattern for the rest? Maybe even _2f_ so it's slightly easier to read.

Also, it'd be nice to have some more tests for the new chars.