[codex] Respect zeroconf-ip on avahi backend

[patrik-sandin]

Summary

This fixes the Avahi zeroconf backend so --zeroconf-ip actually limits which interface(s) get advertised.

Root Cause

launch_avahi accepted zeroconf_ip but discarded it before spawning avahi_task. As a result, the Avahi path always called EntryGroup::add_service with AVAHI_IF_UNSPEC and advertised on every interface, regardless of the requested IP list.

What Changed

• add an Avahi-only ifaddrs helper that maps configured IP addresses to OS interface indices via getifaddrs(3) and if_nametoindex(3)
• thread zeroconf_ip through launch_avahi into avahi_task
• register the Avahi service once per resolved interface index
• fall back to AVAHI_IF_UNSPEC with a warning when resolution fails or yields no matches
• document the fix in the changelog and add the libc dependency required for the Avahi helper

Impact

On Avahi-backed setups, especially Raspberry Pi OS where Avahi is the default backend, --zeroconf-ip now constrains Spotify Connect advertisements to the requested interface(s) instead of leaking onto every local address.

Validation

• cargo build --features with-avahi -p librespot-discovery
• cargo test --features with-avahi -p librespot-discovery
• cargo clippy --features with-avahi -p librespot-discovery -- -D warnings

Notes

I wasn't able to run a live avahi-browse -r _spotify-connect._tcp check in this environment because the workspace is macOS-based and doesn't have a running Avahi daemon.