test(qwp): deflake close-lifecycle interrupt tests on saturated CI agents

[bluestreak01]

Tandem PRs: OSS server CI — questdb/questdb#7387 (pins this branch head for CI validation; move the pin to the merge commit once this lands) · Enterprise e2e — questdb/questdb-enterprise#1127

Summary

Test-only change. Make facadeCloseIsBoundedUnderRepeatedInterruptsDuringQueryCreation and facadeCloseIsBoundedUnderRepeatedInterruptsDuringSenderCreation robust on saturated CI agents: widen the close budget the tests configure from 100ms to 1s, and turn the "storm landed repeatedly" post-join count assert into a synchronized precondition proven while close() is still inside its bounded creation wait.

This addresses the intermittent failure in QuestDB build 254645 (on mac-other): test did not repeatedly interrupt query close, where the interrupt counter read 0/1 while every product-side assertion held.

Root cause

The tests assert, after closer.join(), that a free-running interrupter thread incremented its counter more than once. That is a liveness bet against the scheduler:

• the 100ms creation-wait budget starts ticking when db.close() is called — before the interrupter thread even exists;
• awaitCreationWaiter's poll latency and the interrupter's Thread.start()-to-first-quantum latency are paid out of that same window;
• the interrupter yields after every iteration, sending itself to the back of the run queue on a busy box.

On a hosted 3-core mac agent running sibling surefire forks, the interrupter got at most one quantum inside the window. The failing run's log shows close honoring its deadline exactly (QueryClientPool.close(): 1 query client creation(s) still in flight after 100ms) and returning promptly — the product invariant the test protects (repeated interrupts must not restart the bounded deadline) was intact; only the test's own precondition failed.

Changes

• Widen the creation-wait budget in the two interrupt tests from 100ms to 1s, making the window the storm must land in ~10x the worst observed starvation.
• New awaitRepeatedInterrupts(count, closerStillWaiting, message) helper, called right after interrupter.start(): holds the test until at least two interrupts have landed while the closer is verifiably still inside its bounded wait. The deadline-restart property is now exercised on every run, and a pathologically starved interrupter fails with an explicit close left its creation wait before the interrupt storm landed twice; interrupts landed: N diagnosis instead of a misleading positive-control assert.
• Count-first ordering inside the helper: two interrupts observed while polling count as success no matter how quickly the budget expires afterwards, so the precondition cannot introduce a new race at the boundary.

Validation

• Whole QuestDBImplCloseLifecycleTest class green 3/3 on an idle machine (2.1s — the two tests now deliberately burn their full 1s budgets).
• Both interrupt tests green 3/3 with 3 visible cores (-XX:ActiveProcessorCount=3) while all 12 physical cores were saturated by external spin load — the same starvation conditions as the failing agent.