Roadmap: test coverage, dependency updates, and getting creator/editor/server fully functional

[ctgnz]

Tracking issue for the current jmsfx roadmap. Individual issues have the real detail; this is the map.

1. Unit tests (top priority)

Across all 7 reactor modules there is currently exactly one `@Test` method total, and it's `@Ignore`d - effectively zero automated test coverage anywhere.

• Add unit tests for jmsfx-core's icon composition model #1 - jmsfx-core: `IdentificationSymbol`/`IdentificationSymbolIcon` (the core icon-composition model - highest priority single target)
• Add unit tests for jmsfx-generator's YAML parsing and template generation #2 - jmsfx-generator: YAML parsing (`JmsfxParser`) and template generation

2. Dependency updates

• Decide on and plan the Spring Boot 3.4.5 -> 4.x upgrade #3 - Spring Boot 3.4.5 -> 4.x: needs a real migration-guide read and a decision (3.5.16 stepping-stone vs straight to 4.1.1), not a drive-by bump
• Routine dependency updates across the reactor #4 - Routine updates for everything else (jackson, guava, commons-lang3/text, freemarker, dom4j, jaxb-runtime, jakarta.xml.bind-api, javafx) - verified against actual Maven Central GA releases, filtering out milestone/EA noise

3. jmsfx-creator - mostly functional, missing its headline feature

• jmsfx-creator: implement 'save as composite SVG' #5 - Implement "save as composite SVG" (the one feature named in CLAUDE.md's own description of this module that doesn't exist at all)
• jmsfx-creator: fix UX bugs and rough edges #6 - Fix five independent UX bugs/rough edges found in an otherwise-working app (stale window title, dead progress bar, no-op Graphic-mode switch, silent parse failures, missing null guard)

4. jmsfx-editor - currently a data model with no application on top

• jmsfx-editor: design and build a YAML <-> model persistence bridge #7 - Design and build the YAML <-> model persistence bridge (two disconnected type systems - jmsfx-generator's DTOs and jmsfx-core's interfaces - need a real conversion layer; there's no YAML I/O in this module at all today)
• jmsfx-editor: build the actual GUI application #8 - Build the actual GUI (no `Application`/`Stage`/FXML exists anywhere in the module yet - the property-bound model classes are ready, there's just no window)

5. jmsfx-server - real functional gaps in what looks like working code

• jmsfx-server: fix the broken Generate page (missing endpoints + frontend/backend contract mismatch) #9 - Fix the broken Generate page: missing REST endpoints (404s), a frontend/backend JSON contract mismatch that looks like drift from an older model shape, and a stubbed-out amplifier endpoint
• jmsfx-server: consider migrating off jmsfx-editor's mutable model onto jmsfx-standard's immutable model #10 - Architectural question: should the server even depend on jmsfx-editor's mutable model, or migrate to jmsfx-standard's immutable model like jmsfx-creator already does (would also drop an unnecessary JavaFX-toolkit dependency from a stateless web app)

Suggested rough sequencing

Tests (#1/#2) and the safe dependency updates (#4) can happen anytime and in parallel - they don't block or depend on anything else. The Spring Boot decision (#3) should land before or alongside the jmsfx-server functional fixes (#9/#10), since #10's architecture change touches the same controller code #9's fixes do. jmsfx-creator (#5/#6) and jmsfx-editor (#7/#8) are independent of each other and of the server work.