jmsfx-editor: build the actual GUI application

[ctgnz]

The gap

jmsfx-editor is described (CLAUDE.md) as a desktop app for editing the model file. Investigated the module end to end: there is no GUI at all - zero hits for any `Application` subclass, `Stage`, `Scene`, `FXMLLoader`, `.fxml` file, or launchable `main()` anywhere in `jmsfx-editor/src/main`. This isn't "an editor with rough edges" - it's currently a pure in-memory data model with no application on top of it.

What's already in good shape for this

The `DynamicIconLibrary`/`*Impl` classes are already JavaFX-property-bound (`ObservableList`, `ObjectProperty`, etc.) - genuinely ready for `TableView`/`TreeView`/form binding once there's a window to put them in. This session's earlier fix (see the AmplifierList method-level-generics section in CLAUDE.md) resolved the compile-time issues in this model layer, so the foundation is sound; what's missing is entirely the application layer on top.

Scope

• `Application` subclass + `main()` entry point (matching `jmsfx-creator`'s `IconCreator` as a pattern to follow)
• Main window/views for browsing and editing the model tree (symbol sets, entities/types/subtypes, amplifiers, sector modifiers, etc.) - FXML or code-built, bound to the existing `Impl` classes' properties
• Save/load menu wired to the persistence bridge from jmsfx-editor: design and build a YAML <-> model persistence bridge #7
• Basic validation/feedback for edits (even minimal - e.g. required-field checks before save)

Depends on

#7 (persistence bridge) - there's not much point building editing views before there's a real load/save path underneath them, though the two could be developed in parallel against a stub/in-memory-only persistence layer if that's preferred.

Not yet in scope

Undo/redo, keyboard shortcuts, and other polish - worth their own follow-up once the app exists at all.