Add geo-discovery of providers through a DHT

[flo2517]

Let tenants find providers by geographic proximity and measured latency through a distributed hash table, removing the Control Plane from provider discovery. Today discovery goes through a Control-Plane-held view of the registry; a DHT makes discovery a network property instead of an operator's service.

Blocked by: ADR-017 (see ADR-012 §6) — no implementation before acceptance.

Acceptance criteria:

• ADR-017 selects the DHT and states its Sybil resistance, since an unbounded DHT identity space is the classic attack surface for eclipse and routing attacks;
• advertised location and latency claims are verifiable rather than self-asserted — a provider cannot simply claim to be where it is not, and Implement the Proof of Resource protocol #57 is the mechanism for the resource side of the same problem;
• discovery results are bounded in size and time, and a slow or partitioned DHT yields an explicit timeout, never a silently truncated result presented as complete;
• eclipse, routing-table poisoning, and Sybil flooding are addressed with stated mitigations;
• discovered providers are still checked against finalized on-chain registration and reputation before any lease — the DHT informs discovery, it never grants authority;
• no personal data or precise operator location is published; geographic claims are coarse enough to avoid deanonymizing an operator;
• rollback: the on-chain registry query remains operable alongside the DHT for one release, per ADR-012 §7;
• tests cover discovery, a partitioned DHT, a lying provider, an eclipse attempt, and a provider that is discoverable but not registered on-chain.

---

Original request (FR, preserved verbatim):

Permettre la recherche de providers par proximité géographique et latence via une Distributed Hash Table.