Database Refactor

[sm-28601]

Refactor: Separate SQLite and Supabase implementations into distinct storage modules

Description
Currently, api/database.py is acting as a "God File" for database operations (exceeding 2,000 lines of code). It houses both the Database class (used for local SQLite) and the SupabaseDatabase class (used for remote Postgres) in the exact same file. This violates the Single Responsibility Principle and makes the data layer incredibly difficult to maintain and test.

Proof / Technical Details

• File: api/database.py
• Observation: The file contains massive, duplicated logic for two entirely different database engines.
• Furthermore, despite having an abstract ScanStore interface defined in storage/base.py, neither of these database classes actually inherits from it directly, breaking the intended adapter pattern.

Impact

• Developer Friction: Navigating a 2,000+ line file to fix a simple SQL query is error-prone.
• Testing: It is difficult to mock or unit-test the database layer when both implementations are tightly coupled in the same module.

Proposed Solution

1. Deprecate the monolithic api/database.py file.
2. Split the logic into two distinct modules: storage/sqlite.py and storage/supabase.py.
3. Ensure both new classes explicitly inherit from and implement the ScanStore base class from storage/base.py.
4. Update api/main.py to dynamically import the correct storage adapter based on environment variables.