80: Introduce an explicit Hub-managed JavaFX runtime service

openspec/specs/nenjim-component-registry/spec.md

@@ -186,7 +186,7 @@ The reference Registry construction boundary SHALL create one Registry object ex
 - **THEN** no component ID identifies the manager and no lookup returns it as a component or process
 
 ### Requirement: NenjimHub owns composition and runtime startup
-`NenjimHub` SHALL be the global runtime owner and SHALL expose `start() throws Exception` plus an immutable ordered snapshot of successfully started process IDs. It SHALL be neither a component nor a process and SHALL not register itself. Its only accepted startup attempt SHALL construct the Registry subsystem, start the Registry process first, register it as `nenjim.registry.service`, construct and register the Journal subsystem as `nenjim.journal.service`, start Journal second, and continue to the complete hardcoded business component set from issue #76 only after Journal startup succeeds. During application composition the Hub SHALL construct the Process Manager with itself and register it as `nenjim.process-manager.default`. The Hub SHALL resolve only the explicitly enabled IDs through `NenjimProcess`, start them in dependency-safe order with the Process Manager last, announce the existing online point, and preserve the existing blocking wait. Registration SHALL never imply startup, and the Registry and Journal managers SHALL remain distinct passive, unregistered handles retained privately by the Hub.
+`NenjimHub` SHALL be the global runtime owner and SHALL expose `start() throws Exception` plus an immutable ordered snapshot of successfully started process IDs. It SHALL be neither a component nor a process and SHALL not register itself. Its only accepted startup attempt SHALL construct the Registry subsystem, start the Registry process first, register it as `nenjim.registry.service`, construct and register the Journal subsystem as `nenjim.journal.service`, start Journal second, and continue to the complete hardcoded business component set from issue #76 only after Journal startup succeeds. During application composition the Hub SHALL construct exactly one `JavaFxRuntimeServiceImpl`, register it as `nenjim.javafx-runtime.service`, inject its service view into Mission Control and Process Manager, construct the Process Manager with itself, and register that manager as `nenjim.process-manager.default`. The Hub SHALL resolve only explicitly enabled IDs through `NenjimProcess`, start the JavaFX runtime service after enabled non-JavaFX business processes and before Mission Control and Process Manager, start Process Manager last, announce the existing online point, and preserve the existing blocking wait. Registration SHALL never imply startup, and the Registry and Journal managers SHALL remain distinct passive, unregistered handles retained privately by the Hub.
 
 #### Scenario: Registry starts before graph construction
 - **WHEN** the Hub performs its first startup attempt
@@ -204,17 +204,25 @@ The reference Registry construction boundary SHALL create one Registry object ex
 - **WHEN** the Journal registration has completed
 - **THEN** the same object is retrievable as both `JournalService` and `NenjimProcess` under `nenjim.journal.service`, while its manager is not registered
 
+#### Scenario: JavaFX runtime is process-discoverable
+- **WHEN** Hub-owned application composition has completed
+- **THEN** one object is retrievable as both `JavaFxRuntimeService` and `NenjimProcess` under `nenjim.javafx-runtime.service`
+
+#### Scenario: JavaFX applications share the runtime
+- **WHEN** Hub-owned application composition has completed
+- **THEN** Mission Control and Process Manager retain the same `JavaFxRuntimeService` instance registered by the Hub
+
 #### Scenario: Process Manager is process-discoverable
 - **WHEN** Hub-owned application composition has completed
-- **THEN** the object constructed with the current Hub is retrievable as both `NenjimProcessManager` and `NenjimProcess` under `nenjim.process-manager.default`
+- **THEN** the object constructed with the current Hub and shared JavaFX runtime is retrievable as both `NenjimProcessManager` and `NenjimProcess` under `nenjim.process-manager.default`
 
 #### Scenario: Required hardcoded bindings are registered
 - **WHEN** Hub composition completes
-- **THEN** Journal, the Process Manager, and all component IDs and implementation choices enumerated by issue #76 are present exactly as configured, including intentionally inactive components and excluding both service managers
+- **THEN** Journal, the JavaFX runtime, the Process Manager, and all component IDs and implementation choices enumerated by issue #76 are present exactly as configured, including intentionally inactive components and excluding both service managers
 
 #### Scenario: Explicit startup subset preserves order
 - **WHEN** Hub startup succeeds through the Process Manager phase
-- **THEN** successful process order is `nenjim.registry.service`, `nenjim.journal.service`, `assetaz.ticker.default`, `evelyn.service.prod`, `evelyn.service.test`, `evelyn.iou-burner.prod`, `evelyn.mission-control.default`, and `nenjim.process-manager.default`
+- **THEN** successful process order is `nenjim.registry.service`, `nenjim.journal.service`, `assetaz.ticker.default`, `evelyn.service.prod`, `evelyn.service.test`, `evelyn.iou-burner.prod`, `nenjim.javafx-runtime.service`, `evelyn.mission-control.default`, and `nenjim.process-manager.default`
 
 #### Scenario: Deliberately inactive processes remain inactive
 - **WHEN** Hub startup reaches its online point
@@ -224,6 +232,10 @@ The reference Registry construction boundary SHALL create one Registry object ex
 - **WHEN** Journal process startup throws
 - **THEN** Registry remains the only recorded process, no business component is constructed or started, the exception propagates, and the Hub neither announces online nor enters its final wait
 
+#### Scenario: JavaFX runtime failure is fail-fast
+- **WHEN** JavaFX runtime service startup throws
+- **THEN** its ID is not recorded, Mission Control and Process Manager do not start, the exception propagates, and the Hub neither announces online nor enters its final wait
+
 #### Scenario: Hub start is not retried
 - **WHEN** any first Hub startup attempt has begun and `start()` is requested again
 - **THEN** the later request fails with `IllegalStateException` whether the first attempt succeeded or failed
@@ -233,7 +245,7 @@ The reference Registry construction boundary SHALL create one Registry object ex
 - **THEN** the exception propagates, no later process starts, the Hub neither announces online nor enters its final wait, and no generic rollback or retry is attempted
 
 ### Requirement: Started-process snapshots are ordered immutable and truthful
-`NenjimHub.getStartedProcessIds()` SHALL be safe before, during, and after startup and SHALL return an immutable point-in-time snapshot in successful startup order. A process ID SHALL be appended only after that process's `start()` call returns successfully, including `nenjim.process-manager.default`. Earlier successful entries SHALL remain visible after a later failure, while a failing process SHALL never be included. The snapshot SHALL make no health or continued-liveness guarantee.
+`NenjimHub.getStartedProcessIds()` SHALL be safe before, during, and after startup and SHALL return an immutable point-in-time snapshot in successful startup order. A process ID SHALL be appended only after that process's `start()` call returns successfully, including `nenjim.javafx-runtime.service` and `nenjim.process-manager.default`. Earlier successful entries SHALL remain visible after a later failure, while a failing process SHALL never be included. The snapshot SHALL make no health or continued-liveness guarantee.
 
 #### Scenario: Snapshot before process startup
 - **WHEN** the snapshot is requested before any process has started successfully
@@ -243,6 +255,10 @@ The reference Registry construction boundary SHALL create one Registry object ex
 - **WHEN** a process's `start()` call returns successfully
 - **THEN** its ID appears after all previously successful process IDs in every later snapshot
 
+#### Scenario: JavaFX runtime uses the common recording rule
+- **WHEN** JavaFX runtime service `start()` returns successfully
+- **THEN** the Hub records `nenjim.javafx-runtime.service` through the same post-start rule used for every other process
+
 #### Scenario: Process Manager uses the common recording rule
 - **WHEN** Process Manager `start()` returns successfully
 - **THEN** the Hub records `nenjim.process-manager.default` through the same post-start rule used for every other process