feat(cli): introduce the dirctl doctor network diagnose command

[tkircsi]

Closes #1512

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / verify-proto (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	⏩ skipped	✅ passed	May 26, 2026, 1:16 PM

[codecov]

Codecov Report

❌ Patch coverage is 67.35294% with 222 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cli/cmd/doctor/dht_checks.go	24.6%	92 Missing ⚠️
cli/cmd/doctor/bootstrap_checks.go	62.3%	59 Missing and 1 partial ⚠️
cli/cmd/doctor/api_checks.go	78.6%	22 Missing ⚠️
cli/cmd/doctor/config.go	74.4%	17 Missing and 4 partials ⚠️
cli/cmd/doctor/doctor.go	81.2%	10 Missing and 3 partials ⚠️
cli/cmd/doctor/output.go	91.9%	4 Missing and 4 partials ⚠️
client/config/config.go	68.4%	3 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[ramizpolic]

why do we need this on the client side? the client is currently not aware of the DHT that is used under the hood of a given APIserver.

maybe the approach here would be:

• the client can be: RoutingClient, ApiClient, or Client (which includes both)
• the config for the ApiClient are what we have now (server/issuer/etc)
• the config for the RoutingClient are things needed to interact with a specific network/DHT (routing address, routing keypath, etc)

this would nicely decouple the client into API vs DHT without having to define anything related for diagnostics (since it can be inferred from the configs natively)

[tkircsi]

this is a low level and basic DHT/libp2p network diagnostic tool not only for the client. besides the TCP/gRPC API checks it can help to the operators to validate the DHT part. It checks:

1. is the multiaddress is valid?
2. does this bootstrap peer accept libp2p connection and expose peer metadata?
3. can a temporary DHT client reached bootstrap peer and communicate with it? (ie. populate routing table)

[ramizpolic]

how is that any different from a reusable client for DHT operations (interaction with the low-level DHT outside of the apiserver scope)? defining a DHT-only client helps with decoupling and reusability not only in the Go SDK (client) but also in the CLI and other places.

Im okay not doing it right now, i was only pointing out that the client can be decoupled for DHT-only operations, and probably we could fully reuse the libp2p go client for this, including the config.