Fix: OBD-II reads DTCs the standard way and asks which PIDs exist

[Sherin-SEF-AI]

Defects, found auditing the diagnostics path against SAE J1979

1. Read DTC sent only UDS service 0x19. Every OBD-II vehicle answers mode 03 (stored) and 07 (pending); only UDS-capable ECUs answer 0x19. An older car reported no codes because it was never asked in a language it speaks. Now: modes 03 and 07, then 0x19 as a fallback.
2. Silence was reported as "No DTCs found." If no ECU answered, the tab still said the car was clean. The scanner now records dtc_answered, and the tab says "No ECU answered ... this is not a clean result".
3. The PID scan never asked what the car supports. It requested every table entry, one timeout each. It now reads the supported-PID masks and requests only those, and stops after one question when nothing speaks mode 01.

Coverage

26 → 78 mode 01 PIDs, all single-number values with J1979 formulas: bank 2 trims, fuel pressure, rail pressures, O2 sensor voltages and equivalence ratios, catalyst temperatures, evap pressures (signed), secondary O2 trims, injection timing, engine torque, odometer. PID 0x49 renamed from "Throttle Pos D" to Accelerator Pedal Position D. A payload shorter than the PID's answer is refused rather than misread.

Clearing DTCs is unchanged: still UDS 0x14 behind ARM TX. Adding mode 04 would widen a state-changing action, so it is left alone.

Tests

• A scripted ECU supporting four PIDs: the scan sends exactly 01 00, 01 20 and the four PIDs, with correct values.
• A silent bus: one request, then a clear status.
• DTCs: ["P0133", "P0301 (pending)"] with no UDS request sent; silence gives dtc_answered = False and the tab's not-clean message.
• Formulas against J1979 worked values, including the signed and four-byte PIDs; every PID decodes zeros inside its declared range.

pytest -q: 721 passed. ruff clean. No real OBD-II capture was available, so validation is against the standard and scripted responders.