Send un-prefixed hex to the readmem/writemem/debugreg parser

[JC-000]

What's wrong

#884 made machine:readmem, machine:writemem and machine:debugreg parse their
address and value to the grammar the API documents — hex digits and nothing else.
Two callers in this repository still send the 0x-prefixed form that strtol used to
accept, so against firmware built from test-merge they now get HTTP 400.

tests/e2e/api/rest_api_coverage_test.py:554 is the one that matters. The
PUT /v1/machine:debugreg case writes the register's held value back as a no-op and
formats it set_debugreg(f"0x{before}"). tests/lib/api.py:390-399 raises on any
non-200, so that check fails and the rest-api-coverage suite goes red.

tests/soak/network/http_probe.py sends four 0x-prefixed addresses at :308-311
and the per-runner write address at :290; memory_read and memory_write_verify
raise on any non-2xx, so every memory probe operation raises.

These are the only two. Everything else routes an int through tests/lib/api.py's
_hex_address, which formats {:04X}. (tests/soak/network/dma_probe.py also writes
the debug register, but over the binary DMA socket rather than this parser, so it is
unaffected.)

The change

Send the documented four-digit form. Six lines, no firmware change.

Why fix the callers rather than accept 0x

The prefix was never required — the firmware parses base 16 explicitly — and the
documented grammar is "0000 to FFFF". Loosening the parser again would undo #884.

Test

One Ultimate 64 Elite, measured either side of a single flash.

Before the flash, on firmware predating #884 (git_commit_hash 68b78f50) — this is
the backward-compatibility check, because the change alters what the suite sends for
every target, including benches whose firmware predates #884:

with this change     rest_api_coverage_test: OK (85 checks)   [40] OK
without this change  rest_api_coverage_test: OK (85 checks)   [40] OK

Both pass, so landing this does not break targets that have not been updated. Note the
asymmetry: pre-#884 strtol tolerates the prefix rather than requiring it, so the
un-prefixed pass is the backward-compatibility result and the prefixed pass is merely
the old behaviour.

After the flash, same machine, firmware built from test-merge (bce4535e):

without this change  [40] PUT /v1/machine:debugreg - writing the held value back is a
                          no-op ... FAIL (machine:debugreg returned HTTP 400:
                          {"errors":["Invalid value"]})
                     rest_api_coverage_test: FAIL

with this change     [40] ... OK
                     rest_api_coverage_test: OK (85 checks)

So: green before the flash both ways, red after it without this change, green again with
it. The break is real and comes from the firmware change rather than from anything here.

The bad-address and bad-debugreg stages pass on the same firmware — bad-address: OK (18 checks), bad-debugreg: OK (6 checks) — and neither skips, U64 being absent from
both lacking tuples, so #884 and #885 are confirmed working on this machine.

---

🤖 Generated with Claude Code

[chrisgleissner]

Great find.

[chrisgleissner]

Review after retargeting to master: the strict parser is already in master, so the rebased PR now contains only the caller updates. I found one test-isolation defect: the new debug-register check ended by forcing the register to 1F. Follow-up 3b34b0e writes back the captured value and verifies its read-back instead, so the test leaves diagnostic state unchanged. No other issue found in the caller paths.