Focusing on the former issue, it appears that the new device record is being created just to learn the target state (as discussed in Issues Using Balena Preload), and would be deleted if the device state succeeded. A request to the v2 version of the endpoint succeeds:
$ curl -X GET --header "Content-Type:application/json" --header "Authorization: Bearer $BALENA_TOKEN" --data '{"method": "GET"}' "https://<DOMAIN>/device/v2/7019154e897c4ba5b79e557af8d5a4a7/state"
{"local":{"name":"cold-madness","config":{"BALENA_SUPERVISOR_OVERRIDE_LOCK":"1","RESIN_SUPERVISOR_POLL_INTERVAL":"600000"},"apps":{"1":{"releaseId":17, [etc]
While open-balena-api does have v3 get-state code, a full pull/rebuild of the latest open-balena gets me balena/open-balena-api:v0.192.4, whose src/ only includes routes/state-get-v2.ts.
UPDATE:
Found that the container was being launched by a second, older installation with open-balena 3.6.0. Upgrading that to 3.8.2 did bring support for the v3 state endpoint and allowed the preload to complete. The latest open-balena version might have been earlier when this thread was started.