## Why

Modern JavaFX applications currently submit work through a static helper that
silently initializes the JVM-wide toolkit. That hides an active shared
lifecycle outside the Registry, Hub startup order, constructor dependency
graph, and started-process snapshot established by issues #77 through #79.

## What Changes

- Add a minimal `JavaFxRuntimeService` component API with only non-null
  asynchronous JavaFX Application Thread submission.
- Add one reference object that is both the service and a single-attempt
  `NenjimProcess`; only its `start()` initializes JavaFX, waits for readiness,
  and disables implicit exit.
- Construct and register that object as `nenjim.javafx-runtime.service`, start
  it before enabled JavaFX applications, and record it through the existing
  successful-start mechanism.
- Constructor-inject the same service into Mission Control and Process Manager
  and migrate the four dormant modern JavaFX applications to the same model.
- Remove the static `JavaFxRuntime` utility and document explicit runtime
  ownership and ordering.

## Capabilities

### Added Capabilities

- `javafx-runtime-service`: define the public service, process lifecycle,
  submission rules, consumer injection, and deliberately absent operations.

### Modified Capabilities

- `nenjim-component-registry`: add Hub construction, registration, ordering,
  fail-fast behavior, and started-process tracking for the JavaFX runtime.
- `nenjim-process-manager`: replace the implicit static runtime dependency with
  the injected service while preserving polling and presentation behavior.

## Impact

Affected code is limited to the JavaFX runtime boundary, six existing modern
JavaFX consumers, Hub composition/startup, directly relevant documentation,
and this active OpenSpec change. No configuration, dependency discovery,
events, stop/restart lifecycle, window management, health monitoring,
headless emulation, or broad legacy migration is introduced.