refactor(db): define lifecycle of zero-session Day rows

[wpfleger96]

Problem

Nothing ever deletes a Day row. When a day loses all of its sessions, DayManager._aggregate_day_statistics resets it in place — session_count=0, zeroed event counts, None aggregates — and the shell row persists. Two paths produce these:

• SessionService.delete_sessions (after fix: repair stale day aggregates and demo-scrub metric loss #277 recomputes affected days; behavior locked by tests/unit/test_session_service.py::test_delete_all_sessions_resets_day_stats)
• SessionService.set_session_enabled when the last enabled session of a day is disabled (pre-existing)

Day listings and trend queries will surface these empty shells. Surfaced during review of #277; the persistence itself is pre-existing behavior, consistently mirrored by both paths.

Proposed shape

The two paths need different answers, which is why this is a decision issue rather than a straight fix:

• Disable-all: the Day row cannot be pruned — disabled Session rows still reference it via the composite (day_id, device_id) FK. Options are keeping it (status quo) or filtering session_count == 0 days out of list/trend queries.
• Full delete: the day is truly orphaned (no sessions reference it), so it could be deleted inside the recompute when membership is empty; re-import recreates it via link_session_to_day. Alternatively keep it and rely on the same query-side filtering.

Query-side filtering handles both cases uniformly; pruning on delete is cleaner storage-wise but leaves the disable-all shells behind anyway. Recommend deciding filtering-vs-pruning once, then applying it consistently.

Blast radius

database/day_manager.py and/or the day list/trend query sites, plus the tests that currently assert shell persistence (test_delete_all_sessions_resets_day_stats, the enable/disable suite).