don't log the deliberate multicast re-bind as a socket error

[johncohn]

udpControlSupervisor closes the listener every udpRebindInterval to force a
fresh group join. That close is exactly what unblocks ReadFrom, so the read
loop always lands in its error branch and logs the close it was asked to cause:

kutta: UDP control: read udp 0.0.0.0:9000: use of closed network connection

every 30s, for as long as a multicast listener runs. On an exhibit Pi left up
for an afternoon that was 375 lines of routine maintenance reported as failure.

It reads convincingly like a listener that has died, which is misleading in
exactly the situation the log exists to help with -- while debugging why an
ESP32 knob box wasn't reaching kutta, this cost me a detour before I realised
the socket was fine and the message was self-inflicted.

The fix passes the read loop an atomic.Bool that the supervisor sets just
before a deliberate close, so it can tell that case apart from a socket that
failed on its own. Real errors still log, including on the multicast path --
the flag is only ever set for the re-bind, and is a fresh variable per
iteration. Unicast callers pass nil, since they never close early.

No behaviour change beyond the logging.

Verified with gofmt, go vet, go build, and go test -race ./..., plus on
the Raspberry Pi exhibit where the noise was found.

[crgimenes]

Right diagnosis: the close is what unblocks ReadFrom, so the loop was reporting its own maintenance. Merging, thanks.