fix: harden default request timeout, GraphQL error leakage, and LSP exit halt

[deer]

A default ServerApplication server had no request timeout, leaving it exposed to Slowloris-style slow-request attacks; HttpTransport and HttpTransport.https are now constructed with RequestTimeout.DEFAULT (60 seconds) and MaxRequestSize.DEFAULT instead of leaving both unset. RequestTimeout.DEFAULT is a new constant; callers that genuinely want no timeout can still pass RequestTimeout.NONE explicitly.

GraphQlSchema previously forwarded a data fetcher's raw exception message straight into the client-facing GraphQL error, which could leak internal details like stack state, SQL, or file paths. GraphQlSchema.execute now distinguishes ExceptionWhileDataFetching errors from the GraphQL spec's normal client-facing errors (validation, syntax): the former are logged server-side via a new TelemetryRecorder (settable through GraphQlSchema.Builder.recorder, defaulting to a System.out/System.err recorder) and replaced with a generic "Internal Server Error" message, while the latter continue to pass through with control-character sanitization only. TaskGraphQlHandler now takes a TelemetryRecorder and wires it through from ServerApplication, which exposes its recorder via a new protected recorder() accessor.

LspTransport.tcp binds loopback-only by convention because the exit notification unconditionally calls Runtime.halt, and LSP has no authentication of its own. This adds a second layer: exit now only triggers Runtime.halt when the bound address is actually loopback, determined by InetAddress.isLoopbackAddress(); on any other bind address, exit just closes that connection instead of killing the whole process.