Play Framework

fix(test): use parkNanos(10us) instead of Thread.sleep(1) for watcher sampling

The pool-watcher daemon polls HikariPoolMXBean.getActiveConnections() while
each load runs. Thread.sleep(1) has true sub-ms resolution on Linux/macOS
but is rounded to the ~15ms scheduler quantum on Windows runners.

The first load (/count, /ping) starts on a cold pool — HikariCP physically
opens connections, so each request holds a connection for milliseconds and
even a 15ms sampler catches the window. The second load (/countRo, /pingRo)
hits a warm pool: lease/return is microseconds and a 15ms sampler misses
the active window entirely. Confirmed via tests-results artifact from
windows-latest CI: /countRo assertion failed with "observed max active=0".

LockSupport.parkNanos has microsecond resolution across platforms. With a
10us sleep the watcher samples at ~100kHz, comfortably catching even the
fastest warm-pool lease window.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>