Send the generic-key subList request with the generic key

[RobHofmann]

Send the generic-key subList request with the generic key

Symptom. None visible. The generic-key form (i:1, envelope t:"subList") of the sub-device list request used the device key for its request pack and the generic key for its reply. @p-monteiro flagged that asymmetry while porting PR 507 to 5.0 (#522).

Evidence. @meirlo ran a read-only probe on a GR-Gcloud V3.2.M gateway (comment on #507). A request pack encrypted with the device key, the generic key and a random key all got the same answer: 3 units, readable with the generic key. So the gateway ignores the pack of this form.

Change. get_subunits_list() encrypts the generic-key form with the generic key. The form now uses one key both ways. It stays in the union with the other two forms, because on some gateways it adds units that the other forms miss.

Testing

• Real unit (standalone, subCnt 0, so discovery never sends this in normal use): get_subunits_list() called directly from the dev container. Bind OK, no form answered, result {'list': []}, one warning, no crash. No command sent.
• test_vrf.py harness (fake gateways and units in the dev container): the fake gateway now ignores the request pack of this form, like the real one, and records which key opened it. New check A13 asserts the generic key. 40/40 on this branch; 39/40 on 4.0.9, where only A13 fails (device).
• Compiled in the dev container (Python 3.14). ruff check --isolated shows the same findings as before the change.

Notes

• The same change for 5.0 is a commit on vNext: VRF gateways: ask all sub-device list forms, hold sent values until confirmed #522.
• Evidence comes from one gateway. No gateway is known that reads the pack of this form.