Accepts an all-zero gateway ID from the backend and keeps it for the process lifetime

[pe1mew]

Summary

The forwarder reads the gateway ID from its backend once at startup and
accepts any syntactically valid reply. If the backend answers with an
all-zero ID — which chirpstack-gateway-mesh's border proxy does while (or
after a failed attempt at) fetching the real ID from Concentratord — the
forwarder adopts 0000000000000000 permanently and publishes on
.../gateway/0000000000000000/... topics until the service is restarted.

Observed in production on a border gateway with the Concentratord backend
pointed at the gateway-mesh proxy API: the forwarder connected during the
mesh's startup window, captured zeros, and continued publishing uplinks
under the zero ID.

Suggested fix

Treat an all-zero gateway ID as "not yet available" in the backend setup
and keep retrying — the retry loop for read failures already exists, so
this is a small validation on the successful-read path, e.g. in
src/backend/concentratord.rs where the GetGatewayIdResponse is
validated (alongside the existing length check).

This is defense in depth: the root cause is the mesh proxy answering before
it knows its ID (reported separately against chirpstack-gateway-mesh), but
rejecting an obviously invalid ID protects against any backend misbehaving.

For reference, the same validation was applied in a downstream forwarder
derived from this codebase and verified on hardware without side effects on
the normal path:
https://github.com/pe1mew/chirpstack-ttn-mqtt-forwarder (v0.2.1).

Version: chirpstack-mqtt-forwarder v4.6.0.