…tence load

On cold start, if the first network refresh fails, the flags module would
transition to Error instead of Stale even when valid cached flags existed.

Root cause: DefaultFlagsRepository.hasFlags() read atomicState directly
without calling waitForPersistenceLoad(), unlike every other read method.
The persistence latch had not been counted down yet at the moment hasFlags()
was called inside EvaluationsManager, so it returned false and the module
reported Error instead of falling back to cached Stale flags.

Fix: add waitForPersistenceLoad() call in hasFlags(), consistent with all
other read methods. This is bounded to at most persistenceLoadTimeoutMs
(default 100ms) on first call only, on a background executor thread.

- Switch all remaining version = any() stubs to anyOrNull() so the
  persistence callback is actually exercised rather than relying on
  timeout fallback
- Reduce persistenceLoadTimeoutMs from 5000ms to 500ms in async tests
  so regressions fail fast
- Remove flaky lower-bound elapsed-time assertion (currentTimeMillis
  resolution is too coarse on some JVMs)
- Assert capturedCallback non-null before invoking in integration test
  to surface misconfigured mocks immediately
- Assert awaitTermination returns true and call shutdownNow() in finally
  to avoid leaking threads in failing test runs

Both tests previously fired the persistence callback before hasFlags()
was called, meaning they could pass even without the fix. Now:

- Repository test: runs hasFlags() on a background thread and polls
  Thread.State.TIMED_WAITING before firing the callback, ensuring the
  test fails if hasFlags() does not block on the persistence latch.

- Integration test: captures the executor thread via a custom
  ThreadFactory and applies the same TIMED_WAITING poll before firing
  the callback, guaranteeing the executor is blocked in hasFlags() when
  the persistence callback fires.

Polling loops that wait for Thread.State.TIMED_WAITING would spin
forever if hasFlags() returned without blocking (regression), because
the thread would reach TERMINATED rather than TIMED_WAITING. Adding
TERMINATED as a break condition lets the loop exit immediately in the
regression case, after which the assertion fails fast with a clear
error rather than hanging the test suite.

- Assert capturedCallback non-null before invoking in both async
  repository tests, so stubbing mismatches produce an immediate
  clear failure rather than a silent timeout
- Apply TIMED_WAITING wait pattern to the "no data" async test,
  making it verify hasFlags() actually blocks rather than relying
  on a result that is coincidentally false either way
- Add bounded wait (5s) to the executor thread state poll loop in
  the integration test so a null executorThread produces a fast
  failure with a descriptive message instead of an infinite spin