80: Introduce an explicit Hub-managed JavaFX runtime service

openspec/specs/nenjim-process-manager/spec.md

@@ -4,7 +4,7 @@
 TBD - created by archiving change 79-integrate-process-manager-runtime-status. Update Purpose after archive.
 ## Requirements
 ### Requirement: Process Manager is a Hub-managed process
-`com.r35157.nenjim.npm.NenjimProcessManager` SHALL extend the canonical `NenjimProcess` and SHALL add no public refresh, polling, event, start, stop, or query operation. `NenjimProcessManagerImpl` SHALL require and retain its owning non-null `NenjimHub` as an explicit constructor dependency and SHALL use that Hub as the sole source of displayed process status.
+`com.r35157.nenjim.npm.NenjimProcessManager` SHALL extend the canonical `NenjimProcess` and SHALL add no public refresh, polling, event, start, stop, or query operation. `NenjimProcessManagerImpl` SHALL require and retain its owning non-null `NenjimHub` as the sole source of displayed process status and the non-null shared `JavaFxRuntimeService` as the sole JavaFX Application Thread submission path.
 
 #### Scenario: Process Manager is used through the common lifecycle
 - **WHEN** the registered Process Manager is resolved through `NenjimProcess`
@@ -14,12 +14,20 @@ TBD - created by archiving change 79-integrate-process-manager-runtime-status. U
 - **WHEN** reference Process Manager construction receives a null Hub
 - **THEN** construction fails with `NullPointerException` before startup
 
+#### Scenario: JavaFX runtime service is required
+- **WHEN** reference Process Manager construction receives a null JavaFX runtime service
+- **THEN** construction fails with `NullPointerException` before startup
+
 #### Scenario: Public API remains minimal
 - **WHEN** a consumer examines `NenjimProcessManager`
 - **THEN** it exposes no Process Manager-specific refresh, polling, event, stop, status, or query method
 
 ### Requirement: Process Manager polls immediately on one non-blocking worker
-On its accepted startup attempt, the Process Manager SHALL start or reuse the existing JavaFX runtime mechanism, request the existing Process Manager window, and start exactly one dedicated background polling loop. The loop SHALL request `NenjimHub.getStartedProcessIds()` immediately and again after each normal three-second interval. Polling work SHALL not execute on the JavaFX application thread, and the worker SHALL be a daemon that does not prevent JVM termination.
+On its accepted startup attempt, the Process Manager SHALL request the existing window through its injected already-started `JavaFxRuntimeService` without initializing or starting JavaFX, then start exactly one dedicated background polling loop. The loop SHALL request `NenjimHub.getStartedProcessIds()` immediately and again after each normal three-second interval. Polling work SHALL not execute on the JavaFX Application Thread, and the worker SHALL be a daemon that does not prevent JVM termination.
+
+#### Scenario: JavaFX prerequisite is unavailable
+- **WHEN** Process Manager startup submits its window before the injected JavaFX runtime service has started successfully
+- **THEN** service rejection propagates as Process Manager startup failure and no polling worker starts
 
 #### Scenario: First snapshot is immediate
 - **WHEN** Process Manager startup schedules its JavaFX window and starts its polling worker
@@ -31,14 +39,14 @@ On its accepted startup attempt, the Process Manager SHALL start or reuse the ex
 
 #### Scenario: Polling is not JavaFX work
 - **WHEN** the Hub snapshot is queried and mapped
-- **THEN** that work runs on the dedicated background polling thread rather than the JavaFX application thread
+- **THEN** that work runs on the dedicated background polling thread rather than the JavaFX Application Thread
 
 #### Scenario: Worker does not own JVM lifetime
 - **WHEN** only the Process Manager polling worker would otherwise keep the JVM alive
 - **THEN** its daemon status permits normal JVM termination
 
 ### Requirement: Successful snapshots replace the JavaFX list exactly
-Each successful poll SHALL map every returned `NenjimComponentId` to its exact `value()` string in Hub-provided order and SHALL publish that complete point-in-time list through the existing JavaFX runtime integration. Every JavaFX control mutation SHALL execute on the JavaFX application thread, and publication SHALL replace the complete displayed list rather than infer additions or removals. The existing title, dimensions, and multiple-selection behavior MAY remain unchanged, and no hardcoded process rows SHALL remain.
+Each successful poll SHALL map every returned `NenjimComponentId` to its exact `value()` string in Hub-provided order and SHALL publish that complete point-in-time list through the injected `JavaFxRuntimeService`. Every JavaFX control mutation SHALL execute on the JavaFX Application Thread, and publication SHALL replace the complete displayed list rather than infer additions or removals. The existing title, dimensions, and multiple-selection behavior MAY remain unchanged, and no hardcoded process rows SHALL remain.
 
 #### Scenario: Ordered ID values are displayed
 - **WHEN** the Hub returns an ordered snapshot of component IDs
@@ -54,7 +62,7 @@ Each successful poll SHALL map every returned `NenjimComponentId` to its exact `
 
 #### Scenario: JavaFX controls remain thread-confined
 - **WHEN** the window is created or a successful snapshot is published
-- **THEN** all JavaFX control creation and mutation executes through the existing JavaFX runtime on the JavaFX application thread
+- **THEN** all JavaFX control creation and mutation is submitted through the retained runtime service for execution on the JavaFX Application Thread
 
 ### Requirement: Polling failures preserve the last successful view
 A polling failure SHALL be logged clearly, SHALL enqueue no invented or partial replacement, SHALL not terminate the JavaFX application thread, and SHALL leave the last successfully displayed snapshot visible. The background loop SHALL retry after the next normal three-second interval. If background waiting is interrupted, the worker SHALL restore its interrupted status and terminate the polling loop cleanly. Synchronous failures from the Process Manager's `start()` SHALL remain ordinary fail-fast Hub process-start failures.