REU preflight fails open once c64-test-harness get_config_item returns the item map (harness PR #226) #179

tools/uci/_reu_preflight.py reads the REU config through client.get_config_item(CAT_CART, ITEM) (lines 242 and 268) and unwraps the result with _extract_config_value (line 181), which expects the REST envelope {category: {item: ...}}.

c64-test-harness PR #226 (JC-000/c64-test-harness, issue #214) changes Ultimate64Client.get_config_item(category, item) to return the item map — {"current": ..., "values"|"presets": [...], "default": ...} — and raise Ultimate64ProtocolError when the item is missing. Because this checkout imports the harness through the shared editable venv (~/.local/share/c64-test-harness/venv), the change takes effect here the moment that PR merges to master.

Effect: _extract_config_value does resp.get(category, resp).get(item); with the item map there is no category key and no item key, so it returns None, line ~253 prints WARNING unrecognised shape (...); continuing unchecked, and the preflight's guard against the long AEAD hang is silently gone. The run continues; nothing fails.

Fix (one line each site, or one helper change):

• client.get_config_value(CAT_CART, ITEM) returns "current" directly, or
• keep _extract_config_value and add, before the category descent, if "current" in resp: return str(resp["current"]).
• get_config_item_raw(...) returns the old envelope if the descent must stay as is.

Also worth doing while there: treat an unreadable value as a failure, not a warning-and-continue — the preflight's own docstring says an inconclusive read must not be reported as anything, and a warning line in a long run is not something anyone reads. The same degradation is recorded in c64-wireguard #137 for their tool; the harness-side breaking-change note is in PR #226's body.