feat: Add virtual boards that dynamically group images by date

[Pfannkuchensack]

Summary

Virtual boards are computed on-the-fly via backend queries, not stored in the database. The first virtual board type groups images by creation date into sub-boards per day. The feature is togglable via the board settings popover and the collapse state persists across sessions.

Backend:

• New GET /api/v1/virtual_boards/by_date endpoint returning date-grouped sub-boards with image/asset counts and cover images
• New GET /api/v1/virtual_boards/by_date/{date}/image_names endpoint returning ordered image names for a specific date
• Added get_image_dates() and get_image_names_by_date() to ImageRecordStorageBase / SqliteImageRecordStorage

Frontend:

• "Virtual Boards" toggle in board settings popover (off by default)
• Collapsible "By Date" section in the board list with persist state
• Virtual sub-boards show date, image/asset counts, cover thumbnail, and calendar icon
• Gallery seamlessly loads images when a virtual sub-board is selected
• Virtual boards are read-only: no drag-and-drop, no context menu, no auto-add
• Cache invalidation via VirtualBoards tag on image mutations
• Redux slice migration for new showVirtualBoards and virtualBoardsSectionOpen fields

Related Issues / Discussions

None

QA Instructions

1. Open the gallery panel and click the gear icon to open board settings
2. Enable "Virtual Boards" checkbox
3. A collapsible "By Date" section should appear in the board list with sub-boards for each day that has images
4. Click a date sub-board → gallery shows only images from that day
5. Verify the collapse toggle (caret icon) works and persists across page reloads
6. Verify drag-and-drop onto virtual boards is not possible
7. Generate a new image → virtual board counts should update
8. Disable "Virtual Boards" → section disappears, selection resets to "Uncategorized"

Merge Plan

No special considerations.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)