octaviospain
## Problem The application currently has no way for a user to see its logs. Logging goes only to the console via the `STDOUT` `ConsoleAppender` in `src/main/resources/logback.xml`, so anything logged below the level of a proactively-shown error dialog is invisible to the user. This surfaced during manual testing of playlist import: importing an `.m3u` folder succeeds overall, but audio files that cannot be resolved are logged at `WARN` and then silently dropped. The user is given no indication that some tracks were skipped — the operation looks fully successful. Skipping unresolved entries may be the behavior imposed by the music-commons importer, but the user should at least be able to discover *that it happened* and *which files were affected*. More generally, when a background process (import, export, metadata edit, playback setup, etc.) emits `WARN` or `ERROR` records without throwing a user-facing exception, that information is lost. ## Proposed solution ### 1. Log viewer window Add a resizable window, opened from a menu item in the application menu bar, that displays the application's captured log records. Requirements: - A **non-editable but selectable and scrollable** text area showing log lines (so the user can copy text out). - A **log-level filter** that lets the user choose which levels are shown (e.g. TRACE / DEBUG / INFO / WARN / ERROR), updating the displayed content when changed. - An **export button** that writes the currently held logs to a file the user chooses. - The window is **resizable**, and export lives in the same window as the viewer and the filter. Implementation direction: introduce a logback appender that retains emitted records in memory (bounded/ring-buffered to cap memory use) and exposes them to the viewer. The window reads from that buffer and applies the selected level filter for display; the same buffer backs the file export. ### 2. Status-bar signalling At the end of any process (import, export, or any operation that reports completion), if that process produced `WARN` or `ERROR` records, the status label should indicate this so the user knows to open the log viewer and check. On a clean run the existing success message is unchanged. ### 3. Relationship to the existing error dialog This viewer is **orthogonal** to `ErrorDialogController` / `ErrorPresenter`, which proactively presents `ExceptionEvent` / `ErrorEvent` as modal dialogs. The two coexist: - The error dialog continues to interrupt the user for errors and exceptions raised deliberately. - Anything shown in an error dialog must **also** appear in the log viewer, so the viewer is a complete record of what happened, not just the non-dialog subset. ## Verification - Open the log viewer from the menu bar; confirm it shows current application logs, is resizable, and its text area is read-only but selectable and scrollable. - Change the level filter and confirm the visible lines update accordingly. - Export the logs to a file and confirm the file contents match what is held. - Import an `.m3u` file that references at least one unresolvable audio path; confirm the skipped file is logged at `WARN`, the status label flags that warnings occurred, and the `WARN` line is visible in the viewer. - Trigger an operation that raises an error dialog; confirm the same error is also present in the viewer.