fix: prevent startup panic when database pool creation fails

[tusharmath]

Summary

Fix an app crash at startup caused by DatabasePool::try_from(...).unwrap() when the SQLite database is unavailable (e.g. the file is locked by another process), by deferring pool creation to the first connection request so failures surface as recoverable errors.

Changes

• Replace the fallible TryFrom<PoolConfig> constructor with an infallible DatabasePool::new that stores the config and lazily builds the pool
• Initialize the pool on the first get_connection call, retrying with exponential backoff and caching the pool on success
• Update ForgeRepo::new to drop the unwrap() on pool construction
• Add regression tests covering non-panicking construction with a broken path, error propagation from get_connection, and lazy initialization/caching

Key Implementation Details

The pool is now held as Mutex<Option<DbPool>>: construction never touches the database, and the first get_connection builds the pool under the lock, reusing the existing retry_with_backoff logic that previously ran eagerly in TryFrom. A poisoned mutex is mapped to an error rather than a panic. The in-memory test constructor pre-populates the pool so its behaviour is unchanged.

Testing

Run the new unit tests in crates/forge_repo/src/database/pool.rs: test_new_with_broken_path_does_not_panic_or_connect, test_get_connection_with_broken_path_returns_error, and test_get_connection_initializes_pool_lazily. To verify end-to-end, start the app while another process holds a lock on the SQLite file and confirm it no longer panics at startup.