docs: Document the [telemetry] TLS path readability check

Bring the three documentation surfaces in line with the new parse-time check:

- The @throws clause on makeTelemetrySetup now names the third failure
  condition and records that an empty path is skipped.
- cfg/xrpld-example.cfg states, under all three TLS keys, that with enabled=1
  and use_tls=1 a path that does not exist or cannot be read stops startup. The
  tls_ca_cert wording still says that empty selects the system CA store, since
  only a path that is set is checked.
- The runbook troubleshooting entry gains a third bullet for the "cannot be
  read" message, whose remedy is the path or its permissions rather than the
  certificate and key pairing.

Documentation only; no behaviour change.

include/xrpl/telemetry/Telemetry.h

@@ -431,7 +431,10 @@ makeTelemetry(Telemetry::Setup const& setup, beast::Journal journal);
  * @return A populated Setup struct with defaults for missing values.
  * @throws std::runtime_error  If `enabled` is set and the mutual TLS (mTLS)
  * settings contradict each other: only one of `tls_client_cert`/`tls_client_key`
- * is given, or a client certificate is given while `use_tls` is 0. Those two
+ * is given, or a client certificate is given while `use_tls` is 0. Also if
+ * `enabled` and `use_tls` are both set and a non-empty `tls_ca_cert`,
+ * `tls_client_cert` or `tls_client_key` cannot be read; an empty path is skipped,
+ * so an empty `tls_ca_cert` still means "use the system CA store". All three
  * checks are skipped when `enabled` is 0.
  * @throws boost::bad_lexical_cast  If any numeric key (`enabled`, `use_tls`,
  * `batch_size`, the trace switches, ...) holds a value Section::valueOr cannot