motion: make M62-M68 on a non-existent output an error

[yurc]

M62-M65 and M67/M68 with an output number that motion does not have (P/E >= num_dio/num_aio) are not treated as errors today:

• M64/M65/M68 (immediate): emcmotDioWrite()/emcmotAioWrite() print ERROR: index out of range and return, but the command status is OK, so task carries on and the program keeps running with an output that never switches.
• M62/M63/M67 (synchronized): the bad index goes into the TP queue and is dropped silently; there is no message at all.

This PR refuses EMCMOT_SET_DOUT/EMCMOT_SET_AOUT in emcmotCommandHandler when the index is out of range: it reports an error naming the word and the configured count and sets EMCMOT_COMMAND_INVALID_PARAMS, so usrmotWriteEmcmotCommand() fails and task stops the program at that line. Valid outputs are unchanged.

Reproduce

motmod ... num_dio=4 num_aio=4, then run

M64 P1
M64 P10
M64 P2
G1 X1 F600
M2

Before: ERROR: index out of range, 10 not in [0..4] in the log, then motion.digital-out-02 goes high and X moves to 1 (with M62 P10 or M67 E7 Q1 in place of M64 P10: no message at all, same result).
After: M62-M65 P10: no such digital output (num_dio=4), the program stops; digital-out-02 stays low and X stays at 0.

Tests

New tests/m62-m68-range (python UI, num_dio=4, num_aio=4): M64 P3 and M68 E3 Q2.5 still work; M64 P4, M65 P10, M68 E4 Q1 are refused with an error; a program stops at M64 P10, M62 P10 and M67 E7 Q1 and neither the next line nor the following move runs. It fails on master (12 checks) and passes with this change.

Full scripts/runtests tests/ on Debian trixie, RIP uspace: no new failures (the only failures are the display-dependent pyvcp and ui-smoke/*, the same as on master in that environment).

Docs

docs/src/gcode/m-code.adoc: one sentence each for M62-M65, M67 and M68 that an out-of-range output number is an error and stops the program.

Note: emcmot_command_t.out is an unsigned char, so a P-word of 256 or more still wraps around before it reaches motion; that is left for a separate change.

[grandixximo]

One suggestion on the stop cases and one housekeeping note.

The test should run programs with AUTO_RUN, 0, not 1. 0 is the sentinel for "run from start"; passing 1 triggers the run-from-line skip pass, which discards line-1 canon output (emcTaskPlanLine() <= programStartLine clears interp_list in emctaskmain.cc). Effect here: the M64 P1 on line 1 of the stop-case programs never fires, motion.digital-out-01 stays low even though the line executed. With AUTO_RUN, 0 the line-1 output lands, which also lets the test assert the stop happens exactly at the bad line, not before it:

if not dout(1):
    fail("%s: the line before it did not run (motion.digital-out-01 clear)" % bad)

(output 1 also needs clearing between loop iterations, it latches.) Verified on this branch: with these changes the test passes, and without the motion fix it still fails.

Commit authorship. The second commit (tests, docs: ...) is authored by root <root@claude>, while the first carries your name. Could you amend it so both have your identity before this lands?

[yurc]

Thanks for the AUTO_RUN hint, you're right: 1 makes task skip line 1. I applied all three changes (AUTO_RUN 0, the dout(1) check before the bad line, clearing output 1 between cases) to the test commit, and both commits are now authored by me.

Ran it on an ubuntu:24.04 uspace build of this branch: tests/m62-m68-range passes; with only the motion/command.c change reverted it fails (12 failures: the error text, and the line and move after the bad one still run).

[grandixximo]

Perfect, thanks. All three changes in and both commits clean. LGTM.