Service discovery fails when A/AAAA records arrive before SRV records - entries incorrectly marked as incomplete

### Problem
The library processes DNS records sequentially and immediately creates/updates `ServiceEntry` objects in the `inprogress` map. An entry is only considered `complete` when it has an IP address, port, and TXT record. However, when DNS records arrive in certain orders, the library creates multiple separate entries that never become complete.

### Failure Scenario

1. PTR
2. A (arrives before SRV)
3. SRV
4. TXT

The library creates two separate entries:

- Entry for `device.local.` with an IP, but no port/TXT -> incomplete
- Entry for `device._service._tcp.local.` with port/TXT, but no IP -> incomplete

I encountered this problem with the Alfen EV Charger, but there may be more devices, that send DNS Records in that order. Here are the actual records send by the Alfen:

```
mdns: PTR Record - Name=_alfen._tcp.local., Ptr=ng910-60583-ace0175107._alfen._tcp.local.
mdns: A Record - Name=ng910-60583-ace0175107.local., IP=10.121.63.134
mdns: SRV Record - Name=ng910-60583-ace0175107._alfen._tcp.local., Target=ng910-60583-ace0175107.local., Port=443, Priority=0, Weight=0
mdns: TXT Record - Name=ng910-60583-ace0175107._alfen._tcp.local., Txt=[ContentType=alfen-ace-v1/json Identity=ACE0175107 Type=1.1.1 SCNNetwork= LastConfig=1764777474213 FWVersion=7.3.0-4377 euaEnabled=0 euaConfigured=0 ]
```

A working example for the Keba Charger is here:

```
mdns: PTR Record - Name=_rest-P30-keba-wallbox._tcp.local., Ptr=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local.
mdns: TXT Record - Name=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local., Txt=[devicename=KeContact P30 x-series serialnumber=20963750 alias=KeContact P30 x-series]
mdns: SRV Record - Name=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local., Target=p30.local., Port=8443, Priority=0, Weight=0
mdns: A Record - Name=p30.local., IP=10.121.61.206
```

### Root Cause
The `alias` function is called when `SRV.Target != SRV.Hdr.Name`, but by that time the A-record has already been processed and associated with the wrong entry name `ng910-60583-ace0175107.local.` instead of `ng910-60583-ace0175107._alfen._tcp.local.`. So the alias mapping doesn't propagate the IP address to the service entry.

### Expected behaviour
Device discovery should work regardless of DNS record ordering. The mDNS specification (RFC 6762) does not mandate a specific order for records in responses.

### Question
Is it planned to improve the `alias` function or may there be another fix for that problem? Or is there a fork that already does this?