Make short polling timeout configurable in provider validation tests

[affandar]

Problem

The short polling validation tests in src/provider_validation/long_polling.rs have a hardcoded 100ms threshold:

// Lines 27-31 (orchestration)
assert!(elapsed.as_millis() < 100, 
    "short-poll returned too slowly: {}ms (expected <100ms)",
    elapsed.as_millis());

// Lines 110-113 (worker)
assert!(elapsed.as_millis() < 100,
    "short-poll returned too slowly: {}ms (expected <100ms)", 
    elapsed.as_millis());

This works well for local/low-latency backends like SQLite, but causes flaky test failures for network-based providers like PostgreSQL where:

• Each stored procedure call takes ~70-80ms over network
• Query plan compilation on first execution adds overhead
• Connection pool establishment adds latency

Current Workaround (in duroxide-pg)

We've had to add warmup queries before the short-poll tests to pre-warm the connection pool and query plan cache:

// Warm up the connection pool and query plan cache with TWO dummy fetches
// The first primes the connection, the second warms the query plan cache
let _ = provider.fetch_orchestration_item(Duration::from_secs(1), Duration::ZERO).await;
let _ = provider.fetch_orchestration_item(Duration::from_secs(1), Duration::ZERO).await;

Proposed Solution

Make the timeout threshold configurable via ProviderFactory:

pub trait ProviderFactory: Send + Sync {
    async fn create_provider(&self) -> Arc<dyn Provider>;
    fn lock_timeout(&self) -> Duration;
    
    // New: configurable threshold for short-poll timing assertions
    fn short_poll_threshold(&self) -> Duration {
        Duration::from_millis(100)  // Default maintains backward compatibility
    }
}

Then use it in the assertions:

let threshold = factory.short_poll_threshold();
assert!(elapsed < threshold,
    "short-poll returned too slowly: {:?} (expected <{:?})",
    elapsed, threshold);

This would allow:

• Local providers (SQLite): Use default 100ms
• Network providers (PostgreSQL, CosmosDB): Configure 200-300ms based on expected latency

Environment

• duroxide version: 0.1.11
• Affected provider: duroxide-pg (PostgreSQL)
• Test failure rate: ~30% without warmup workaround