Make the addresses wire-pod uses for robots configurable

[Mikeycallin1]

Fixes the problem in #532, and the one reported in #213.

The problem

wire-pod assumes two things that only hold on a flat LAN:

1. it can discover its own robot-facing address via GetOutboundIP()
2. the address a robot connects from is the address to dial to reach it

Behind a reverse proxy, a container bridge or a router, every robot arrives at
the same gateway address. That address gets stored against each robot and later
dialled for the SDK app, camera stream and jdocs — so wire-pod ends up calling
the proxy instead of the robot. The robot reports as unreachable while being
perfectly healthy.

What this adds

Two addresses, kept deliberately distinct because conflating them breaks TLS:

	direction	used for
robot_facing_address	inbound	what robots dial. Goes into the certificate SANs and server_config.json, which must agree or the robot's pinned-leaf handshake fails
robot_lan_addresses	outbound	per robot — what wire-pod dials to reach that robot

Behind a proxy the peer address is also useless as an identity key, since
several call sites look a robot up by its stored address. So a robot is
identified by the ESN it reports on the connection check (?emresn=), or by
its own token's requestor_id on refresh.

UI: a checkbox and address field in the first-run wizard; a per-robot address
table in Bot Setup, shown only when proxy_mode is on. The address can also be
captured automatically during BLE adoption.

Existing installs are unaffected

Everything is off unless proxy_mode is set:

• the new config fields are omitempty, so a default install's
  apiConfig.json stays byte-identical
• no certificate is regenerated — regenerating de-pairs every paired robot, so
  it stays a deliberate admin action. A coherence check only warns
• botSdkInfo.json keeps its exact on-disk shape
• identity resolution is gated too, deliberately. On a direct LAN the peer
  address is the better signal, and preferring the reported ESN there would
  retire the mDNS browse that repairs a robot's stored address after DHCP
  moves it

Testing

The repo has no test CI, so these only run when invoked:

cd chipper && go test ./pkg/vars/... ./pkg/servers/token/... \
  ./pkg/wirepod/setup/... ./pkg/wirepod/sdkapp/...

They concentrate on what could damage an existing install: config
byte-identity, write-then-reload round trips, certificate/server_config
coherence, and both gates asserted at the level of their consequences rather
than their return values — for example that a stock install does not rewrite a
robot's stored GUID from an unverifiable token claim.

Happy to drop the tests from the PR if you would rather not carry them.

What is not covered

The two BLE reads in the adoption capture need real hardware, so they are
manually verified only. The decision logic around them is in an untagged file
and is tested.

[bliteknight]

ngl, this is a lot for something that can be resolved by reserving your Vectors IP so it doesn't change.

Also don't Vectors broadcast their IP via mDNS just like WirePod does? - it seems it would be easier during Vector discovery to update the IP automatically so this reverse proxy is not needed (I would need to verify this)