docs(telemetry): Document the otel choice in the [insight] section

The comment said statsd was the only server choice. otel is also accepted, and
an operator reading this had no way to learn that.

It also records what does not carry over: the [telemetry] section owns the
export destination and the resource attributes on that path, so address and
prefix are ignored, and endpoint reaches a startup log line without changing
where metrics go.

cfg/xrpld-example.cfg

@@ -1267,10 +1267,10 @@
 #
 #     "server"
 #
-#       Choice of server to send metrics to. Currently the only choice is
-#       "statsd" which sends UDP packets to a StatsD daemon, which must be
-#       running while xrpld is running. More information on StatsD is
-#       available here:
+#       Choice of server to send metrics to, either "statsd" or "otel".
+#
+#       "statsd" sends UDP packets to a StatsD daemon, which must be running
+#       while xrpld is running. More information on StatsD is available here:
 #           https://github.com/b/statsd_spec
 #
 #       When server=statsd, these additional keys are used:
@@ -1281,6 +1281,13 @@
 #       "prefix"  A string prepended to each collected metric. This is used
 #                 to distinguish between different running instances of xrpld.
 #
+#       "otel" exports the same metrics over OTLP instead, and needs a build
+#       with telemetry compiled in. The [telemetry] section below owns the
+#       export destination and the resource attributes, so "address" and
+#       "prefix" do not apply. An "endpoint" key is read on this path but
+#       only appears in a startup log line; it does not change where metrics
+#       are sent.
+#
 #     If this section is missing, or the server type is unspecified or unknown,
 #     statistics are not collected or reported.
 #