led-bridge: manage the serial connection lifecycle (reconnect on drop)

[Julie Krasnick (jckras)]

Summary

Makes led-bridge resilient to the serial device coming and going. Previously it opened the serial port once at construction and held that handle forever — so if the ESP ever reset or dropped off USB (a reflash, a USB blip, a loose connection), led-bridge kept writing to a now-dead handle. Every write failed with EIO, last_state froze at the last successfully-written value, and it stayed stuck until viam-server was restarted. It also failed to build at all if the device wasn't present at startup.

This reworks the connection as a managed lifecycle: the port can be absent, drop, and return, and led-bridge rides all of it.

What changed (all in resources/led-bridge/led-bridge.go)

• One path for connect & reconnect — openLocked() opens the port on demand; a nil port simply means "disconnected." First-connect, reconnect-after-drop, and absent-at-boot all flow through the same code, so there's no special-case "reopen" branch to keep in sync.
• Self-heals on drop — a failed write closes the stale handle, so the next write reconnects to the live device. The "stuck forever on the last state" failure is gone.
• Reconnect backoff — redials are throttled (reconnectBackoff, 2s) so an absent device isn't dialed every tick. Important because opening the port resets the ESP — unthrottled retries would reboot-loop it.
• Build-safe — construction no longer fails if the device is missing. led-bridge comes up connected: false, logs it, and connects when the device appears (instead of the whole resource going unavailable).
• Observability — Status() now reports a connected flag alongside the existing write-health counters.

No new goroutine: reconnection rides the existing poll loop, which is correct for a write-driven service (a disconnect only matters at the next write, which is exactly when reconnection triggers).

Notes

• Follows up on LED indicator: led-bridge pulls lifecycle state from voice-command #14 (the LED indicator feature), branched off main.
• Root cause in practice was a loose solder joint + the always-open handle compounding; the joint was fixed in hardware, and this makes the software robust to any future drop on its own.

Test plan

• go build ./... and go vet pass
• Unplug/replug the ESP while running → led-bridge logs reconnect and messages_sent resumes, no viam-server restart needed
• Reflash the ESP while running → led-bridge recovers on its own within ~2s
• Start viam-server with the ESP unplugged → led-bridge builds, reports connected: false, then connects when plugged in
• Status() shows connected: true and last_state tracking voice-command during normal operation