fix: Watch-folder DB inserts silently failed on phantom added_at column (#211)

[deucebucket]

Closes #211

Summary

Three `INSERT` statements in the watch-folder worker targeted a phantom column `added_at` on the `books` table. The real column is `created_at` — only the `queue` table has `added_at`. Every insert raised `sqlite3.OperationalError` which two separate `except` blocks caught with `logger.debug`, hiding the error at default log levels.

Bug has existed since the watch-folder feature was introduced. Surfaced during live testing of #209 when I noticed a watch-folder failure produced no UI row despite clean log output.

Effects before this fix

• Successful watch-folder moves never produced a `pending` or `needs_attention` row in the `books` table.
• Failed watch-folder moves never produced a `watch_folder_error` row — the UI had no surface for the failure; only the log showed it.
• The root cause was masked by `logger.debug` at default log levels.

Changes

`app.py`

• Renamed `added_at` → `created_at` in three books-table INSERTs:
  • Line 6906 (INSERT OR REPLACE for `needs_attention` — watch folder unknown author)
  • Line 6914 (INSERT OR REPLACE for `pending` — watch folder known author success)
  • Line 6944 (INSERT for `watch_folder_error` — watch folder move failure)
• Raised swallow-except log level from `logger.debug` → `logger.warning(..., exc_info=True)` in both watch-folder DB blocks (lines 6926 and 6950). Same class of silent failure can't rot unnoticed again.

Verification

• Schema confirmed: `.schema books` on production DB has `created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP`, no `added_at`. The `queue` table has `added_at` which is where the remaining legitimate references live.
• All other `added_at` references in `app.py` target the `queue` table — verified with `grep -n 'added_at' app.py`.

Test plan

• `python3 -m py_compile app.py` → SYNTAX OK
• `ruff check app.py --select=F821,E9,F63,F7,F82` → All checks passed
• `venv/bin/python test-env/test-naming-issues.py` → 290 passed, 0 failed
• Live test on maintainer LM: drop a file in watch that fails to move (cross-fs hardlinks per [BUG] when LM fails to create hardlinks, it copies and deletes original file #209 scenario), verify `SELECT status, error_message FROM books WHERE status='watch_folder_error'` returns the item with the full error message.
• Live test happy path: drop a processable file, verify a `pending` (or `needs_attention` if author unknown) row appears in books.

References

• Surfaced during live testing of [BUG] when LM fails to create hardlinks, it copies and deletes original file #209 (hardlink data-safety fix)
• Follow-up for [BUG] watch_folder_processed is in-memory only + add handler for Skaldleita server_notice #208 (watch-folder persistence), which now records dedup in its own table; this PR fixes the separate `books` table tracking

[bucket-agent]

🔍 Vibe Check Review

Context

Tiny, tightly-scoped fix renaming a phantom added_at column to created_at in three watch-folder INSERT INTO books statements, plus raising two swallow-except handlers from debug to warning(..., exc_info=True).

Codebase Patterns I Verified

• Read library_manager/database.py:28-37 — books table schema has created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, no added_at column. The fix's claim is ground truth.
• Searched all other INSERT INTO books sites (lines 4999, 5055, 5136, 5253, 5316, 5366, 5447) — none reference added_at; they omit the timestamp columns and rely on DEFAULT. Only the 3 watch-folder inserts had the bug.
• Confirmed added_at is a real column on a different table (queue.added_at at database.py:71) — explains how the typo slipped in and why other added_at grep hits in app.py are legitimate.
• Verified APP_VERSION bump to beta.149 aligns with CHANGELOG entry dated 2026-04-17.

✅ Good

• Root-cause fix (wrong column) plus symptom fix (silent swallow). Both needed — fixing only one would leave either a broken feature or a future invisible failure.
• exc_info=True on the elevated warnings preserves the traceback, which is exactly what you want when a silent failure surfaces.
• Inline comments at app.py:6906 and app.py:6949 explain WHY the log level was raised (issue #211 reference) — aligns with CLAUDE.md's "explain non-obvious why" guideline.
• Documentation discipline: CHANGELOG + README + version badge all updated together, beta.149 entry honestly describes scope.

🚨 Issues Found

No issues found.

📋 Scope Verification

Issue	Problem	Addressed?	Notes
#211	Watch-folder failure-tracking silently swallows DB errors (debug-level log)	✅	Fixed BOTH the swallow (warning + exc_info) AND the underlying OperationalError (column rename). No scope creep.

Scope Status: SCOPE_OK

📝 Documentation Check

• CHANGELOG.md: ✅ Updated (beta.149 entry, 2026-04-17, clear effects + fix description)
• README.md: ✅ Updated (version badge + Recent Changes blurb)

🎯 Verdict

APPROVE