Swing feature component architecture

Design Swing UI as isolated feature components with unidirectional data flow, explicit state, and clear EDT and lifecycle ownership. Introduce the smallest architecture that cleanly separates responsibilities; do not enforce MVC, MVP, MVVM, or MVI by name.

Workflow

1. Read the local module instructions and inspect the whole feature boundary, including callers, services, listeners, asynchronous work, and disposal.

2. Map ownership of rendering, user intent, UI state, application logic, asynchronous work, navigation, and lifecycle.

3. Choose the lowest architecture level that makes those responsibilities clear.

4. Keep Swing in the View, coordinate behavior in the Controller when one is needed, and keep application services independent of Swing.

5. Make data flow one-way where state or workflows are non-trivial:

   user -> View --Intent--> Controller --calls--> Services
             ^                  |
             '--- render(State)-'