feat: virtual thread support

Adds a single flag that switches the framework's concurrent work over to virtual threads:

Operator operator = new Operator(override -> override.withUseVirtualThreads(true));

It can also be set with josdk.use-virtual-threads. It is off by default, so nothing changes for
existing operators.

Why

Reconcilers spend almost all their time blocked on the Kubernetes API server or on external
systems. Virtual threads make that kind of blocking cheap, so concurrency limits can be raised far
above what is reasonable with platform threads, without sizing and tuning thread pools.

What changes when the flag is on

Java 25 only

Virtual threads are supported on Java 25 and later (JEP 491
removed the carrier pinning inside synchronized blocks, which the codebase uses extensively; on
Java 21 to 24 it can starve the carrier pool and deadlock startup). This is checked at runtime: on
an older JVM a warning is logged and platform threads are used, so one configuration works on every
Java version the operator runs on. The compilation target stays Java 17.

Scheduled executors (the larger part of this PR)

Previously PollingEventSource and TimerEventSource each created a java.util.Timer, and
PerResourcePollingEventSource created its own ScheduledThreadPoolExecutor. Each cost a thread
that the operator neither sized nor shut down. They now use scheduled executors that are created
and shut down in a defined way:

• Polling event sources get an executor of their own. PollingEventSource and
  PerResourcePollingEventSource do not share an executor, so a slow poll of one source never
  delays another. Unless one is provided with withExecutorService on the configuration builder,
  the source creates a single-thread daemon executor when it starts and shuts it down when it stops
  (a new one on every start). With useVirtualThreads on, that executor runs the polls on virtual
  threads. A provided executor is used as is, is never shut down by the source, and may be shared
  deliberately.
• ConfigurationService.getRetryAndRescheduleExecutorService() backs the retry and reschedule
  timer of every controller. It is managed by ExecutorServiceManager, sized with
  concurrentRetryAndRescheduleThreads() (default 2) or
  josdk.retry-and-reschedule.concurrent-threads, and can be replaced through
  ConfigurationServiceOverrider. The operator shuts it down on stop and creates a new one when
  started again.
• The default pools use daemon threads, drop tasks scheduled for later on shutdown (so far-out
  reschedules don't delay termination), remove cancelled tasks eagerly, and let idle threads time
  out after 60 seconds.
• Event sources resolve their executor on every start() rather than at construction. The polling
  and timer sources let a poll or handler already in flight finish when stopped, as the Timer
  they replace did, and the timer source re-arms its pending timers on the operator's new executor
  when the operator is started again.
• ExecutorServiceManager.scheduledExecutorService() stays available for compatibility,
  deprecated, as a general purpose executor created on first use. The framework itself no longer
  uses it.

VirtualThreadScheduledExecutor

The JDK has no scheduled executor backed by virtual threads, so with the flag on the defaults are a
new package-private VirtualThreadScheduledExecutor: one daemon platform thread does the timing
and hands each fired task to a virtual-thread-per-task executor.

• The number of scheduled tasks running at once is not limited in this mode, because they are
  typically blocking calls. withConcurrentRetryAndRescheduleThreads only applies to platform
  threads.
• It keeps the semantics of the default platform executor: waiting and periodic tasks are discarded
  on shutdown(), and tasks that have already started are let finish. shutdownNow() interrupts
  running tasks.
• Fixed-rate tasks make up missed executions after an overrun, as ScheduledThreadPoolExecutor
  does. Fixed-delay tasks re-arm from completion time.

Other changes

• Executor helpers live in an internal ExecutorUtilsInternal.
• ConfigLoader and ConfigurationServiceOverrider expose the new settings
  (josdk.use-virtual-threads, josdk.retry-and-reschedule.concurrent-threads).
• The webpage sample operator now runs with virtual threads.
• spotbugs exclusion for the VirtualThreadScheduledExecutor handles. They are ordered by remaining
  delay but must stay distinct by identity, as the JDK's own scheduled futures.

Documentation

• operations/configuration.md: new "Virtual Threads" section, which points to "Keeping the JVM
  Alive" for operators whose main returns, and the new configuration keys.
• eventing.md: "Threading of the polling event sources", with the per-source executor and who
  owns it.

Testing

Unit tests, with the virtual thread ones gated by @EnabledForJreRange(min = JAVA_25):

• VirtualThreadScheduledExecutorTest: virtual thread execution, cancellation, fixed delay and
  fixed rate, overrun catch-up, shutdown semantics, unbounded concurrency.
• VirtualThreadsTest, BoundedVirtualThreadExecutorAuditTest: bounded virtual thread executor
  and fallback on old JVMs.
• VirtualThreadsStartupDeadlockTest: startup with virtual threads does not deadlock.
• ExecutorServiceManagerTest, ConfigurationServiceOverriderTest: lifecycle and overriding.
• PerResourcePollingEventSourceTest, PollingEventSourceTest, TimerEventSourceTest: each source
  owning its executor (and not sharing it), provided executors left running, virtual threads,
  restart, stop and start ordering, polling resilience.
• ExecutorUtilsInternalTest: idle pool threads time out and delayed tasks still run.

Integration test: VirtualThreadsIT runs a full operator with the flag on.

Known limitations and follow-ups

• Only Java 25 and later is officially supported for virtual threads.