Resume-at-line spindle recovery ignores zero-padded M03 commands

[righteousgambit]

Summary

Resume-at-line recognizes zero-padded M03 as spindle-on state, but its spindle-speed helper only searches for the literal form M3. An interrupted program using M03 S... can therefore resume with a bare M3 instead of explicitly restoring its programmed spindle speed.

The mismatch exists on develop at 2ea66c10e96d88013a04441134d3d4f8e8c88510: the speed helper uses M3(?![0-9]) in duplicated scans (spindle-speed recovery), while the general command matcher normalizes numeric command values and therefore recognizes M03 as M3 (token matching). When mode recovery succeeds but speed recovery returns None, the preview emits bare M3: resume spindle recovery.

The Community Firmware only updates the stored spindle speed when an S argument is present: firmware spindle handling.

This is related to but distinct from #528, which tracked missing resume metadata when the local cached file was unavailable. This reproduction supplies the G-code lines and specifically isolates zero-padded M03 speed parsing.

Minimal reproduction

M03 S12000
G1 X1 F100
G1 X2

Preview a resume at line 3.

Expected:

• The preview contains buffer M3 S12000.

Actual:

• Spindle mode recovery recognizes M03, but speed recovery returns no value.
• The preview contains a bare buffer M3.

Impact

This does not imply a deterministic dead spindle: the firmware can retain an earlier speed when bare M3 is received. The resumed RPM can nevertheless be stale, wrong, or zero depending on retained state. Explicitly restoring the S value from M03 S... removes that state dependency.

Acceptance criteria

• Recover spindle speed from both M3 and zero-padded M03.
• Support S before or after the command and tightly packed tokens.
• Do not misclassify other commands such as M030.
• Ignore command-like text in comments.
• Cover helper behavior and the emitted resume command with regression tests.