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.

[rajpratham1]

Thanks for the fix! This is a solid improvement to the database initialization flow.

Replacing the eager pool creation and unwrap() with lazy initialization makes startup much more robust, especially when the database is temporarily unavailable or locked. The new implementation surfaces initialization failures as recoverable errors instead of crashing the application, which is a much better user experience.

I also appreciate the added regression tests covering:

• construction with an invalid database path,
• recoverable connection failures,
• lazy initialization behavior, and
• successful pool caching after first use.

The refactoring keeps the API straightforward while improving reliability. Looks good to me—nice work!

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.