Validate --address flag format in pipectl client options

What would you like to be added:

Add address format validation to Options.Validate() in pkg/app/pipectl/client/client.go to catch malformed --address values before they reach grpc.DialContext().

Proposed approach:

1. Use net.SplitHostPort to validate standard host:port format (including IPv6 like [::1]:9000).
2. If that fails, fall back to url.Parse for gRPC resolver URIs (e.g. dns:///localhost:9000).
3. After both, verify the result has a non-empty host (for host:port) or scheme (for resolver URIs) — rejecting inputs that parse but carry no meaningful address, such as ://bad or localhost (missing port).
4. Add table-driven unit tests using testify/assert covering valid, invalid, and edge cases.

Why is this needed:

Currently Options.Validate() only checks if --address is empty. Any non-empty malformed input passes through to grpc.DialContext(), producing cryptic multi-line transport errors like:

desc = "transport: Error while dialing: dial tcp: address localhost: missing port in address"

This is confusing for users and makes debugging harder. Since the Options struct is shared by all pipectl subcommands (application, deployment, encrypt, event, planpreview, transfer, plugin), this affects every pipectl user.

If this approach aligns with what you had in mind , I can proceed with the implementation . If you have a different approach in mind, I'm happy to adjust

Start in pkg/app/pipectl/client/client.go at Options.Validate() and inspect nearby tests before running them. Add table-driven coverage for host:port, IPv6, resolver URIs, and malformed addresses using testify/assert. Done means invalid --address values are rejected before grpc.DialContext(), while valid addresses remain accepted.