Switch zone services need per-rack distinction in DNS

Currently we do not differentiate switch zone services by rack, nor do we differentiate them by which switch "slot" (0/1, top or bottom) they manage. However, this information is required since the switch configuration per-rack and per-slot will not necessarily be the same. We are currently getting around the lack of per-slot identification in DNS by querying the co-resident MGS service and learning the location from it, but we should resolve both of these problems by changing how we register the services in DNS.

Example of how we do it today:
https://github.com/oxidecomputer/omicron/blob/05b37debe3b76c42188c2efafee56b65e7605674/nexus/src/app/background/sync_switch_port_settings.rs#L238-L258

Possible solution:
Dendrite and MGS are both in the same zone, and IIUC Dendrite registers itself with DNS. Dendrite (and other services like it) could first query MGS to learn what slot / location they manage, and provide that as part of the information / name registered to DNS. If we could figure out a way to provide a rack ID to the sled-agents / switch zones upon startup, the switch zone service could also provide that information during their registration to DNS.

Start with the DNS-related behavior referenced in nexus/src/app/background/sync_switch_port_settings.rs, especially the linked lines, and trace how switch services currently use the co-resident MGS service to learn their location. Then investigate the Dendrite, MGS, sled-agent, and switch-zone registration paths mentioned in the issue. Done means DNS registrations distinguish both rack and managed switch slot without relying on the current workaround.