fix: reset OtelJulHandler circuit breaker on reconfiguration

[om7057]

Fixes #1291

OtelJulHandler installs a circuit breaker on its JUL to OTLP log bridge: the first RuntimeException thrown from the emit path sets disabled = true, and publish() short-circuits on that flag from then on. Nothing in the class ever set it back to false. A single transient failure, for example the OTLP endpoint being briefly unavailable, or a reconfigure/shutdown race, permanently stops all controller and pipeline log export for the remaining life of the JVM. Traces are unaffected since they go through a separate exporter, which masks the outage.

The class already implements OpenTelemetryLifecycleListener but did not override afterConfiguration(ConfigProperties), so a JCasC reload or any other SDK reconfiguration never re-fetched the logger provider or reset the breaker. The only thing that previously cleared it was a brand new handler instance, meaning a JVM restart or plugin reload.

This change overrides afterConfiguration to re-fetch the logger provider from openTelemetry.getLogsBridge() and clear disabled, so a reconfigure recovers a previously tripped handler. The disabled field is also made volatile since publish() can run on arbitrary logging threads while afterConfiguration() runs on the reconfiguration thread.

Testing done

Added OtelJulHandlerTest with two tests:

• handlerNeverRecoversWithoutAfterConfiguration: reproduces the original bug, a single emit failure permanently disables the handler and every subsequent publish() is a no-op.
• afterConfigurationResetsTheCircuitBreaker: asserts calling afterConfiguration() clears the breaker and a subsequent publish() attempts to emit again.

Ran the full existing test suite locally on JDK 21 (matching this repo's Jenkinsfile): 238 tests run, 0 failures, 0 errors, 1 skipped (pre-existing skip, unrelated to this change). Also verified ./mvnw spotless:check and ./mvnw spotbugs:check pass clean.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed