FMC scrambles are not random state

[torchlight]

The middle part of the scramble sequences obtained by trimming out the R' U' F padding at the start and the end is filtered by csTimer to only be states where min2phase.js will not produce a solution starting with R* (or L* R*) or ending with F* (or B* F*). This eliminates approximately a third of all possible 3×3×3 scrambles from being generated with the 333fm scrambles.

js> cst_scrambles = `R' U' F R' U' F D' F U' R' F' U L2 F2 L2 F2 U2 F2 U' R2 D' L2 U' F R' U' F
R' U' F R2 B' D2 U2 B2 L' F2 L D2 F2 L' D2 L R' D' F2 L' D' F' L B' R' U' F
R' U' F B R2 U' L2 B2 R2 F2 D2 L2 D' B2 D B' U L2 D R D2 R2 U2 R' U' F
… (300 scrambles in total, not included here) …
R' U' F U2 B' D R2 F2 L2 R2 F2 D' B2 D' R2 F2 L' D R B' U2 B2 D' R' U' F`.split('\n');
js> cst_scrambles_middle = cst_scrambles.map(x => x.substring(8,x.length-8));
js> cst_scrambles_middle.filter(x => min2phase.solve(min2phase.fromScramble(x))[0] === 'R').length
0
js> cst_scrambles_middle.filter(x => min2phase.solve(min2phase.fromScramble(x)).trim().split(/ +/g).pop()[0] === 'F').length
0

The last two lines should output some number around 1/6 of the total number of scrambles tested (which is 300/6 = 50 here) on proper random-state scrambles, not 0.

(I actually don't completely understand what the code is doing—it seems like it should be filtering for the inverse's solution to not start with F* and not end with R*, but that's not what I'm seeing with the actual scrambles generated by csTimer. In any case, it's still wrong. TNoodle-lib seems to do the correct thing, which is to search for solutions that don't cancel moves with the R' U' F padding, rather than for scrambles with solutions that don't cancel moves.)