Settings cannot be re-applied after being read for 13 images

[jasiek]

Summary

Reading a radio's settings and applying them straight back fails for 13 images. Upload aborts with the generic wrapper:

RuntimeUnsupportedError: Radio settings validation failed before upload

Behind that wrapper, _validate_and_apply_radio_settings (web/python/runtime_bridge.py:970) reports four distinct causes. This is the settings-side analogue of #31: in most cases the read path emits values the write path refuses.

Categories

A. Value CHIRP itself emitted is rejected — 1 image

Retevis_C2.img:

dtmf.dtmf_local_id: Value '1234    ' contains invalid character ` '

The trailing-space padding comes from the driver's own stored value. Exactly the to_csv / really_from_csv asymmetry from #31, in the settings tree.

B. Current value is not in the setting's own option list — 3 images

Retevis_MA1:   basic.backlight   -> "8 is not valid for this setting"
Retevis_MA1:   basic.p1          -> "Enter is not valid for this setting"
Retevis_RA685: advanced.savemode -> "On is not valid for this setting"
Retevis_RA85:  advanced.savemode -> "On is not valid for this setting"

The image holds a value the driver does not list as selectable. Reading is fine; writing the same value back is refused.

C. Setting disappears between read and re-apply — 4 images

Icom_IC-F621-2:     group_continuous_tone, group_scan
Quansheng_UV-K5:    basic.language
Retevis_HA2:        aprsinfo.anaptttype, aprsinfo.aprsaudio
Wouxun_KG-UV920P-A: rmt_grp.rc_sw, rmt_grp.rc_power

Setting is not available for this radio image. — the settings tree built on re-apply does not contain a path that was present when reading. Related to settings-need-backing-state in FINDINGS.md: these drivers build the tree conditionally from image content, so a tree serialized from one instance does not necessarily map onto a freshly constructed one.

D. Validation crashes — 5 images

Yaesu_FT-25R, FT-4VR, FT-4XE, FT-65E, FT-65R:
  misc.cw_id  -> object of type 'NoneType' has no len()
  misc.passwd -> object of type 'NoneType' has no len()

Not a validation failure but an exception surfacing as one. A setting whose value is None reaches a length check. Worth fixing first — it is the only category that is unambiguously a defect on our side rather than a data/driver mismatch.

Reproduction

const loaded = await harness.loadCodeplugBinary(raw);   // read settings
await harness.runPythonJson(`
_r = _import_radio_class(_m, _c)(memmap.MemoryMapBytes(bytes(
    chirp_common.CloneModeRadio._strip_metadata(base64.b64decode(_b))[0])))
_res = _validate_and_apply_radio_settings(_r, json.loads(_s), apply_changes=True)
json.dumps({"valid": _res["valid"], "issues": _res["issues"]})`,
  { _m: match.module, _c: match.className, _b: b64, _s: JSON.stringify(loaded.settings) })

Suggested order

1. Category D — stop the NoneType crash; a None value should serialize and validate as empty.
2. Category A — accept values the driver emitted, mirroring the Reading a radio and writing it back unchanged fails for 113 of 248 models #31 approach of letting the driver's own validation decide.
3. Categories B and C — need per-driver triage; C may not be fixable by replaying a serialized tree at all, and may want re-reading the tree from the same instance instead.

Measured across chirp/tests/images/ after #32.