Play Framework

fix: harden cache + Hikari Micrometer wiring (release 1.12.37)

PF-86 audit follow-up. Closes three gaps in the PF-85/PF-86 metrics
binding identified during a code review:

* HikariDataSourceFactory.setPoolName(dbConfig.configName) — every
  hikaricp_* meter is now tagged pool=<dbName> instead of Hikari's
  auto-generated HikariPool-N. Multi-DB setups produce one
  human-readable series per data source.
* HikariDataSourceFactory.rebindAllToRegistry(MeterRegistry) — new
  static method that walks DB.datasources and re-attaches the
  MicrometerMetricsTrackerFactory to every active HikariDataSource.
  MetricsPlugin.onApplicationStart calls it after Metrics.install,
  closing the dev-mode hot-reload gap where DBPlugin.changed() returns
  false, the existing Hikari pool is reused, and its tracker keeps
  emitting to the previous PrometheusMeterRegistry that
  MetricsPlugin.onApplicationStop already closed. No-op on cold start
  (DB.datasources is empty when slot 30 runs before slot 300).
* CaffeineImpl.bindMetrics Javadoc — corrected the contradictory
  "Safe to call multiple times" wording to make clear that
  CaffeineCacheMetrics.monitor registers fresh gauges on every call
  and re-binding the same registry would duplicate meters.

Also adds MetricsFunctionalTest under test-src/integration/ — boots the
real Netty server, hits /@metrics, and asserts the body contains the
expected cache_size{cache="play_cache"}, cache_gets_total,
hikaricp_connections{pool="default"}, and jvm_memory_used_bytes lines.
The pool="default" assertion specifically pins the new setPoolName
path; a regression to HikariPool-1 would fail loudly. The in-process
FunctionalTest.GET path can't exercise this — only PlayHandler invokes
rawInvocation, so the scrape endpoint requires a real server bind.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>