[#300] Make BufferPool.get honor its timeout when allocating a buffer

[vharseko]

Problem

BufferPool.get() honored its timeout budget only on the mustClaim path (claiming a buffer that already holds the wanted page). On a pool miss, allocBuffer() performed a single clock sweep of 2 × bufferCount ticks and then threw a raw IllegalStateException("No available Buffers"). Sweep ticks are wasted on touched, claimed, or transiently non-detachable buffers, and the clock is shared, so concurrent sweepers race past each other's candidates — on a small hot pool a thread can stochastically burn its whole sweep and fail a plain read instead of waiting.

Surfaced by TransactionTest2.transactionsWithInterrupts on a windows-latest CI cell (run 30011500179): a worker died with No available Buffers during the 10-second interrupt storm against the 20-buffer test pool, tripping the worker-death assertion added in #288.

Fix

• allocBuffer() returns null on sweep exhaustion — as its javadoc already promised — instead of throwing.
• get() retries the whole lookup with a short sleep (RETRY_SLEEP_TIME, 50 ms) until the timeout budget expires, then throws a checked InUseException, matching the method's documented contract. The sleep happens after the finally has released the hash-lock stripe, and each retry re-searches the hash table in case another thread loaded the page meanwhile.
• The claim path and the allocation path now share a single budget measured from get() entry, which also removes the old unbounded-wait pathology where every outer-loop continue restarted the mustClaim clock.

Tests

• testGetHonorsTimeoutWhenPoolExhausted — with every buffer writer-claimed, get() for an absent page fails with InUseException and not before its timeout expires (the old behavior — an immediate IllegalStateException — fails both assertions).
• testGetWaitsForReleasedBuffer — a get() blocked on an exhausted pool succeeds as soon as another thread releases a buffer, and not earlier. Pool exhaustion is only declared after two consecutive allocation failures so a transient claim by a background thread is not mistaken for exhaustion.

Verified locally: BufferPoolTest (7/7), TransactionTest2#transactionsWithInterrupts plus related (4/4, balance agrees), BufferTest, BufferTest2, BufferMaxPack, MVCCPruneBufferTest, VolumeTest all green.

Fixes #300