## Why

Issue #75 left the Journal subsystem on a manager-owned lifecycle, while issue
#77 established `NenjimHub` as the runtime owner and `NenjimProcess` as the
canonical active lifecycle. Journal must use that common model before later
runtime work can depend on it consistently.

## What Changes

- Make `JournalService` a registrable Nenjim component while keeping its query
  API read-only and filesystem-independent.
- Make the reference Journal service object the single-use active
  `NenjimProcess`, with atomic publication after a complete successful initial
  filesystem load.
- Reduce `JournalServiceManager` to the passive `journalRoot()` and `refresh()`
  administrative capability, bound through a non-public admin view.
- Add an implementation-only Journal assembly that provides identical service
  and process views plus a distinct manager.
- Have `NenjimHubImpl` register and start `nenjim.journal.service` immediately
  after the Registry and before every business process.
- Preserve Journal format, parsing, chain, query, refresh and filesystem
  semantics while updating directly affected documentation.

## Capabilities

### Modified Capabilities

- `nenjim-journal-management`: move lifecycle and initial loading from the
  manager to the service process, add startup query gating and the safe
  construction boundary, and preserve explicit refresh.
- `nenjim-component-registry`: extend Hub-owned composition, startup order,
  started-process history and fail-fast behavior with the Journal process.

## Impact

Affected code is limited to the Journal public contracts and reference
implementation, the Hub composition root, directly affected architecture
documentation, and this active OpenSpec change. No Journal data format,
business-service behavior, configurable autorun, stop lifecycle, Context,
resolver, classloader, watcher or general test suite is added.