2024 Genesis G80 HDA2: ADRV traffic present but no ADAS ECU response at 0x730

### Describe the car bug

## Vehicle and setup

- 2024 Genesis G80 2.5T Sport Prestige, US market, HDA II
- comma 4
- sunnypilot staging, using upstream opendbc Hyundai interface/safety behavior
- Exact platform match: `GENESIS_G80_2ND_GEN_FL`
- Camera firmware: `99211-T1210` (fingerprint PR #3604)
- Radar firmware: `99110-T1120`
- Platform flags: `8197`
- `CANFD_LKA_STEER_MSG`
- `CANFD_ALT_GEARS`
- `CANFD`

Lateral control and stock Genesis SCC work normally. Current opendbc reports:

```text
alphaLongitudinalAvailable=False
openpilotLongitudinalControl=False
pcmCruise=True
radarUnavailable=True
```

## What is unusual

The car has the stock CAN messages expected from an HDA II ADAS-driving
topology:

| Message | Bus | Approximate rate |
|---|---:|---:|
| `0x50` LKA steering | camera CAN | 100 Hz |
| `0x51` ADRV | A-CAN | 100 Hz |
| `0x160` ADRV | E-CAN | 50 Hz |
| `0x1A0` `SCC_CONTROL` | E-CAN | 50 Hz |
| `0x1EA` ADRV | E-CAN | 20 Hz |
| `0x200` ADRV | E-CAN | 20 Hz |
| `0x345` ADRV | E-CAN | 5 Hz |

However, firmware-query requests sent to ADAS address `0x730` receive no
response at `0x738`. Camera `0x7C4/0x7CC` and radar `0x7D0/0x7D8` respond
normally.

I scanned every standard diagnostic frame in `0x700-0x7FF`, the queried
29-bit diagnostic addresses, and all `carFw` entries. No unidentified positive
firmware response appears to represent the ADAS Driving ECU at another queried
address.

## Comparison with the existing 2024 G80 Advanced route

Reference route from the original G80 support work:

```text
66eaa6c3b6b2afc6/00000009--3a5199aabe/0
```

Sport Prestige route:

```text
ffe7d2315938753c/00000293--5a61d55cfe/0
```

The reference Advanced route has the same flags (`8197`), same relevant
message locations/rates, and also no response at `0x738`.

Its recorded `CarParams` says `alphaLongitudinalAvailable=True`; the current
Sport Prestige route says `False`. This appears to be a software-version
difference rather than a hardware-topology difference. Current
`CarInterface._get_params()` explicitly forces alpha longitudinal unavailable
for `CANFD_LKA_STEER_MSG` vehicles when `Ecu.adas` is absent:

```python
if lka_steering and Ecu.adas not in ecu_list:
# this needs to be figured out for cars without an ADAS ECU
ret.alphaLongitudinalAvailable = False
```

I have not found evidence that openpilot longitudinal was actually validated
on the Advanced reference vehicle; the route only establishes that the older
software exposed the option.

## Factory service information

The 2024 G80 factory service manual documents a distinct physical
`ADAS Driving ECU (ADAS_DRV)` behind the main crash pad. Its connector has
E-CAN and ADAS-CAN pairs. Replacement requires factory diagnostic-tool
`variant coding`.

The module's DTC catalog includes:

- E-CAN bus-off
- ACC/SCC communication error
- HDA variant-coding mismatch
- front-camera timeout
- front-radar timeout
- front-corner-radar timeout

This confirms the platform design includes this module, but the generic manual
does not prove that it is installed on every trim or reachable from the
camera-harness diagnostic path.

## Previous radar test

A parked test addressed the responding SCC radar at `0x7D0`. The radar
accepted diagnostic session `10 03`, but stock `SCC_CONTROL` continued after
communication-control request `28 83 01`, and Panda correctly raised
`relayMalfunction`. The vehicle recovered after an ignition cycle. I will not
repeat this or send additional disable commands without maintainer guidance.

## Questions

1. Was openpilot longitudinal ever validated on the 2024 G80 Advanced reference
vehicle, or was only lateral/stock SCC validated?
2. For this RG3 topology, is the missing `0x738` response evidence that
`ADAS_DRV` is physically absent, or could factory gateway/diagnostic routing
make it unreachable from the camera harness?
3. Is there another known diagnostic endpoint/bus for `ADAS_DRV` on RG3, or
should this platform remain explicitly gated from alpha longitudinal?
4. What additional **read-only** route data would be useful before considering
any further active vehicle test?

This differs from #3395: that Niro's `0x730` ECU responds and accepts the
disable command before gateway traffic disappears. This G80 never responds at
`0x730`, while its normal ADRV message set remains present.

Related fingerprint PR:

https://github.com/commaai/opendbc/pull/3604

Vehicle investigation:

https://community.sunnypilot.ai/t/2024-genesis-g80-2-5t-sport-prestige-hda-ii-car-unrecognized/6420

### Provide a route where the issue occurs

ffe7d2315938753c/00000293--5a61d55cfe/0

### openpilot version

sunnypilot staging 2026.002.000, commit 3bd5475499cc9a66b018fa9be041334eaaa82e40

### Additional info

_No response_

Start with CarInterface._get_params() and compare the referenced Advanced and Sport Prestige route data, including the listed CAN and diagnostic addresses. Review the route at ffe7d2315938753c/00000293--5a61d55cfe/0 and the comparison route to establish whether longitudinal control was validated and whether ADAS_DRV is reachable. Done means documenting the supported topology and an evidence-based gating decision without further active vehicle tests.

Written by the indexing model from the issue text.