fix: Validate the connect ip parameter

[SoubeDev]

doConnect checked that ip was present but never that it was a string, while the sibling port field is type checked with isConvertibleTo. The unguarded asString() then failed in two different ways.

For an array or an object, asString() hits JSON_ASSERT_MESSAGE, which throws json::Error. The throw was swallowed by the dispatch catch-all, so a malformed value produced a generic internal error rather than invalidParams, and the request was recorded as a server fault in the perf log.

Every scalar was worse, because it was silently coerced instead: 42 became "42", 1.5 became "1.500000", true became "true" and null became "". None of those parse as an address, so isUnspecified() was true and the connect was skipped, yet the handler still returned "attempting connection to IP:true port: 2459". The caller was told a connection had been attempted when none ever was.

Guard the conversion with an isString() check and return invalidParams when it fails, reusing RPC::expectedFieldError so the error matches the family the port path already returns.

The commandline is unaffected. RPCParser::parseConnect always assigns jss::ip from a std::string, whether the argument is given as ip and port or as a single ip:port, so the new check can never fire there.

Connect_test only covered the standalone rejection, which returns before any parameter is read. Split it into standalone, missing ip and invalid ip cases, with a helper that leaves standalone mode so the parameter checks become reachable; connect is a Condition::NoCondition command, so no other part of dispatch reads that flag.

Fixes #6744

High Level Overview of Change

Context of Change

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)