Toyota: RADAR_PRE_FAULT causes intermittent false radar unavailable events

### Describe the car bug

# Toyota: RADAR_PRE_FAULT causes intermittent false radar unavailable events

### Describe the car bug

After updating to a version containing commaai/opendbc#3452, I started getting intermittent disengagements / "Communication Issue Between Processes" alerts while driving.

I traced the failure through the logs and found that the initial cause is `radarTracks` becoming invalid due to:

```text
radarUnavailableTemporary: True
canError: False
radarFault: False
wrongConfig: False
```

The underlying Toyota radar status at one occurrence was:

```text
600.003 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=652
601.873 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=909
606.973 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=1166
612.073 RADAR_STATUS=1 RADAR_PRE_FAULT=3 INVALID_COUNTER=1359
612.873 RADAR_STATUS=1 RADAR_PRE_FAULT=3 INVALID_COUNTER=1102
614.273 RADAR_STATUS=1 RADAR_PRE_FAULT=3 INVALID_COUNTER=845
615.573 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=652
616.173 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=395
617.173 RADAR_STATUS=1 RADAR_PRE_FAULT=0 INVALID_COUNTER=138
```

`RADAR_STATUS` remains `1` throughout. The temporary-unavailable condition begins exactly when `INVALID_COUNTER` crosses the documented pre-fault threshold and `RADAR_PRE_FAULT` changes from `0` to `3`.

This then propagates as:

```text
RADAR_PRE_FAULT=3
-> radarUnavailableTemporary
-> radarTracks invalid
-> radarState invalid
-> longitudinalPlan / driverAssistance invalid
-> disengagement / communication issue alert
```

There is no corresponding CAN failure (`canError=False`).

This behavior appears to have started after the `RADAR_PRE_FAULT` check was added in #3452. I noticed the discussion on that PR also mentioned the possibility of false positives from this signal.

### Local workaround / test

For testing, I changed:

```python
if self.rcp.vl['STATUS_MSG']['RADAR_STATUS'] != 1 or self.rcp.vl['STATUS_MSG']['RADAR_PRE_FAULT'] != 0:
ret.errors.radarUnavailableTemporary = True
```

to:

```python
if self.rcp.vl['STATUS_MSG']['RADAR_STATUS'] != 1:
ret.errors.radarUnavailableTemporary = True
```

I have now driven **25+ hours** with this change and have not reproduced the issue. Prior to the change, it occurred consistently but seemingly at random. I did test without my change again afterwards and had it happen within 2 hours; and had it happen quite frequently in a 4:30~ hour trip

This leaves the `RADAR_STATUS` handling intact and only stops treating `RADAR_PRE_FAULT` by itself as `radarUnavailableTemporary`.

I'm not necessarily suggesting that ignoring `RADAR_PRE_FAULT` entirely is the correct upstream fix. It may make more sense to debounce it, combine it with another indication of actual radar degradation, or otherwise handle the pre-fault differently. I wanted to report the behavior and the A/B result before opening a PR.

### Environment

* sunnypilot branch: `tn-prebuilt`
* sunnypilot version: `2026.09.01-4826`
* sunnypilot commit: `5c37fd3cedf867b90137dc7e76f464d94df3eb18`
* affected code originates from: commaai/opendbc#3452

### Example log

```json
{
"event": "commIssue",
"invalid": [
"longitudinalPlan",
"radarState",
"driverAssistance",
"alertDebug",
"lateralManeuverPlan",
"modelDataV2SP"
],
"not_alive": [
"alertDebug",
"lateralManeuverPlan"
],
"not_freq_ok": [
"alertDebug",
"lateralManeuverPlan"
]
}
```

At the same time, `radarTracks` reports:

```text
radar errors: {
'canError': False,
'radarFault': False,
'wrongConfig': False,
'radarUnavailableTemporary': True
}
```

I can provide the relevant rlog/route and additional occurrences if useful.

### Provide a route where the issue occurs

7527757a368fcb70/0000025c--2573190273/0

### openpilot version

2026.09.01-4826 (sunnypilot tn-prebuilt, commit 5c37fd3cedf867b90137dc7e76f464d94df3eb18)

### Additional info

#3446 @sshane

Start by reviewing the Toyota STATUS_MSG handling that sets radarUnavailableTemporary and compare it with the change in commaai/opendbc#3452. Use the provided route and logs to reproduce the RADAR_PRE_FAULT transition; done means preventing false radar-unavailable events while preserving handling for genuine radar status failures.

Written by the indexing model from the issue text.