Refactor: Improve SQLite error handling and integrate logger in albums database layer

### Describe the bug or improvement
The database module `backend/app/database/albums.py` currently executes SQLite operations directly without wrapping them in `try...except sqlite3.Error` blocks. When database queries fail, the errors are raised silently to the API layer without being logged locally. This is inconsistent with the rest of the database modules (like `images.py`, `folders.py`, `faces.py`, and `metadata.py`), which have been updated to capture, log, and handle SQLite exceptions using the project's standard logger.

Additionally, the route file `backend/app/routes/albums.py` should catch these database errors and log them, and use `except HTTPException: raise` to prevent catching and hiding explicit HTTP exceptions within `except Exception` blocks.

### Proposed Solution
1. In `backend/app/database/albums.py`:
- Import `get_logger` from `app.logging.setup_logging` and initialize the logger.
- Wrap SQL execution blocks (like `cursor.execute`) in `try...except sqlite3.Error as e:` blocks.
- Log the database errors with `logger.error(...)` before re-raising.
2. In `backend/app/routes/albums.py`:
- Add `except HTTPException: raise` to prevent wrapping HTTP status codes in standard 500 errors.
- Log any unexpected errors.

This is a good first issue for backend cleanup!