Function mdns_instance_label 

fn mdns_instance_label(hostname: &str, port: u16) -> String

Build this instance’s DNS-SD instance name — the first label of the service fullname. Must be BOTH unique per running instance AND free of dots.

Both properties were violated before 2026-09-06, and together they broke LAN discovery outright between two hosts on the same build:

• Not unique. The name was format!("agentmux-{instance_id}"), and instance_id is the version (config.rs’s args.instance, which the launcher sets to e.g. v0.55.37). Every host on the same release therefore registered the identical name, and handle_event’s self-skip — which compares incoming fullnames against our own — discarded genuine peers as if they were us.
• Not a single label. v0.55.37 contains dots. In DNS-SD the instance name is ONE label and dots must be escaped; nothing escaped them, so mdns-sd split at the first dot, treated agentmux-v0 as the label and .55.37 as part of the service type. Observed verbatim in a peer’s log as agentmux-v0 (2).55.37._agentmux._tcp.local. — note the conflict suffix landing mid-version-string.

The two compounded: the collision triggered mdns-sd’s conflict-renaming, and because service_fullname was captured before register() (fixed alongside this), the renamed host kept a stale self-name that exactly matched the OTHER host’s real name — so the renamed host silently dropped every announcement from its peer, permanently, with no self-heal. That is why discovery was observed to work in one direction only.

hostname + port is unique per instance (hostname per machine, port per srv on that machine) and carries no version, which is deliberate: a version does not belong in an identity key, and it was the version being in there that created the cross-host collision. Any character that isn’t alphanumeric, - or _ is replaced, so a FQDN hostname (box.corp.example) or an exotic one can’t reintroduce the dot bug.