feat: provider egress geolocation ingest and integration

[Ryanmello07]

Summary

Adds server-side ingest and integration for provider egress geolocation: an operator-run prober determines a provider's real egress location and submits it, and the server prefers that over the built-in mmdb lookup when resolving where a provider is.

The motivation is cost and decentralization. Accurate city-level IP geolocation currently requires a paid database, which every network operator would have to buy independently. Geolocating a provider by probing through it — so the geolocation source reports the provider's own egress IP — gets the country reliably for free, from sources that already answer that question. This PR is the server half; the prober itself lives in a separate operator tool.

This also means the location reflects where user traffic actually exits, rather than where the provider's control connection happens to originate — those can differ for multi-homed or NAT'd providers.

What's here

• provider_egress_location table, keyed by client_id (append-only migration, IF NOT EXISTS, no FKs, no backfill, no lock on existing tables).
• POST /network/provider-egress-location — operator-authenticated via a vault shared secret (provider_egress.yml, key ingest_secret), constant-time compared. Fails closed: if the secret is absent or empty, every request is rejected, and a missing vault resource disables the endpoint rather than crashing the api.
• SetConnectionLocation prefers a fresh stored egress location and otherwise falls back to the existing mmdb path unchanged — on a miss, a stale entry, a non-provider client, or an error writing the probed location.
• A taskworker sweep that drops long-expired entries, so a provider that stops being probed reverts to the mmdb path instead of being pinned to a stale location.

Only country-confident submissions are accepted; city/region are stored only when the submission is also city-confident. In practice free geolocation sources agree on country but frequently disagree on city, so most locations resolve at country granularity by design.

Included bug fix

The first commit fixes a latent panic that this feature would otherwise hit constantly:

network_client_location requires city_location_id and region_location_id NOT NULL, but a country-granularity location row has them NULL. SetConnectionLocation inserted those NULLs directly, panicking inside server.Tx. That panic escapes the connection announce goroutine, whose HandleError wrapper cancels the connection context — tearing down the client's connection right after auth, and (because the panic hits before the disconnect-cleanup defer is registered) orphaning the connection row as connected=true.

How often it fires depends on the geo database's city coverage: rare with a full commercial dataset, constant with a sparse one. It is included here because this feature makes country-granularity locations the common case.

Compatibility

Fully backward compatible and inert until deliberately enabled:

• With no ingest secret configured the endpoint rejects everything, nothing is ever stored, and SetConnectionLocation behaves exactly as before.
• The migration only adds a new table.
• Probed providers still get the ARIN "foreign network" cross-check, so they are ranked on the same terms as unprobed ones.

Testing

27 tests across model, controller, and api/handlers, covering the storage layer, submission validation and rejection paths, the auth gate (including that it accepts a correct secret, not only that it rejects bad ones), and all four fallback paths.

Note for reviewers running locally: the three mmdb-fallback tests need a geo database whose schema ip.go supports (DB-IP or ipinfo). With an unsupported fixture they fail with Unknown schema type, which is a fixture mismatch rather than a code failure.