78: Make JournalService a Hub-managed Nenjim process and integrate it into startup

docs/Nenjim.md

@@ -1,9 +1,9 @@
 #<center><H1>Nenjim<br>Documentation</H1></center>
 
 > **Dokumentstatus:** Journal-format version 1, den immutable Java-model, den interne tekstparser, det read-only
-> `JournalService`, den eksplicit refresh-baserede `JournalServiceManager` og første version af det centrale
-> component Registry er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat
-> fremtidig funktionalitet.
+> `JournalService` med en Hub-styret procesimplementation, den passive eksplicit refresh-baserede
+> `JournalServiceManager` og første version af det centrale component Registry er implementeret. Contexts,
+> resolution, discovery, runtime loading og removal er fortsat fremtidig funktionalitet.
 
 **Indholdsfortegnelse:**
 <!-- TOC -->
@@ -125,16 +125,23 @@ state ændres. Alle publicerede modeller og collections er immutable og defensiv
 
 ### 2.8 JournalService, JournalServiceManager og disk-layout
 
-En `Service` er det domæne-API, som applikationer og andre services bruger i daglig drift. `JournalService` er derfor
-filesystem-uafhængigt og read-only: det kan vise coordinates, kronologiske revisionslister, latest, exact og
-newest-at-or-before snapshots samt en eksakt release fra et valgt snapshot. Det eksponerer ikke start/stop,
-filesystem paths, refresh, parser eller mutation.
+En `Service` er det domæne-API, som applikationer og andre services bruger i daglig drift. `JournalService` er en
+registrerbar Nenjim component, men API'et er fortsat filesystem-uafhængigt og read-only: det kan vise coordinates,
+kronologiske revisionslister, latest, exact og newest-at-or-before snapshots samt en eksakt release fra et valgt
+snapshot. Det eksponerer ikke lifecycle, filesystem paths, refresh, parser eller mutation. Queries er først
+tilgængelige, når Journal-processens initiale loading er lykkedes.
 
-En `ServiceManager` ejes af en composition/lifecycle owner og håndterer start, stop, configuration/data location,
-refresh og adgang til den tilhørende Service. `JournalServiceManager` ejer den normaliserede Journal-root. Ved start
-læser referenceimplementationen komplette UTF-8-filer kronologisk, validerer placement/navne og gør først sit
-`JournalService` tilgængeligt, når hele initial loading er lykkedes. Refresh er explicit og idempotent; der er ingen
-watcher eller background polling, og stop ændrer ikke Journal-filer.
+En `ServiceManager` er et separat administrationshandle, som en composition/lifecycle owner kan beholde uden at
+give almindelige service-consumers administrative rettigheder. `JournalServiceManager` er passiv og eksponerer kun
+den normaliserede Journal-root og explicit refresh; den har ingen `start()`, `stop()` eller service-accessor og er
+hverken component eller process. Hub'en konstruerer ét Journal-objekt, som både er `JournalService` og
+`NenjimProcess`, samt en separat manager bundet til objektets package-private admin-view.
+
+Når Hub'en starter Journal-processen, læser referenceimplementationen komplette UTF-8-filer kronologisk og
+validerer placement/navne. Hele den initiale worldview publiceres først, når alle runtime-filer er accepteret; en
+fejl efterlader servicen utilgængelig uden partial state og samme instans kan ikke startes igen. Refresh efter
+vellykket startup er fortsat explicit, idempotent og per-ingestion atomisk; der er ingen watcher eller background
+polling.
 
 `JournalServiceImpl` vedligeholder internt kæderne og udfører atomisk ingestion med exact-text SHA-256. Identisk tekst
 er idempotent; anderledes tekst med samme coordinate og Journal-version er en conflict. Parser, ingestion og mutable
@@ -156,7 +163,7 @@ data/nenjim/journals/
 ```
 
 Kun `.journal` er runtime-input. `.journal.example` dokumenterer formatet og indlæses ikke. Roden skal allerede
-eksistere og være læsbar; service-manageren opretter, overskriver eller sletter ikke Journal-filer.
+eksistere og være læsbar; Journal-processen og dens manager opretter, overskriver eller sletter ikke Journal-filer.
 
 ## 3. Opdateringer og Sikkerhed
 Det implementerede Journal-lag kan repræsentere nye sikkerhedsoplysninger som en nyere immutable revision, for
@@ -167,9 +174,9 @@ upgrade/downgrade er fremtidigt arbejde.
 Betaling og AssetAZ-integration er langsigtet vision og er ikke en del af Journal-formatet eller denne implementation.
 
 ## 5. Backing Store og Fleksibilitet
-Den nuværende `JournalServiceManagerImpl` læser kun det dokumenterede lokale disk-layout. Artifact downloading, IPFS retrieval,
-remote Journals og andre backing stores er ikke implementeret. En `ipfs:`-værdi i `INFORMATION_URI` er metadata,
-ikke en retrieval-instruks.
+Den nuværende Journal-proces læser kun det dokumenterede lokale disk-layout gennem en intern filesystem-loader.
+Artifact downloading, IPFS retrieval, remote Journals og andre backing stores er ikke implementeret. En
+`ipfs:`-værdi i `INFORMATION_URI` er metadata, ikke en retrieval-instruks.
 
 ## 6. Standardiseret og Automatiseret Pakkehåndtering
 Journalen modellerer dependency-krav og indholdsidentiteter, men downloader ikke bytes og verificerer ikke downloadet
@@ -201,12 +208,17 @@ Det kan returnere et immutable registration-order snapshot af ID'er for et compo
 gennem et forventet interface. Et manglende ID giver `null`; et eksisterende ID med forkert interface er en caller
 programming error. Public API'et kan ikke registrere eller fjerne componenter.
 
-`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en konstruerer Registry-subsystemet og hele den
-nuværende hardcodede component graph, ejer dependency wiring og vælger de processer, som skal startes. Et
+`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en konstruerer Registry- og Journal-subsystemerne samt
+hele den nuværende hardcodede component graph, ejer dependency wiring og vælger de processer, som skal startes. Et
 implementation-only Registry assembly udleverer read-only service-view, process-view af det samme Registry-objekt
 og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive registrationshandle: den er hverken
 component eller process, har ingen `start()` eller service-accessor, registreres ikke og starter aldrig en component.
 
+Et tilsvarende implementation-only Journal assembly udleverer read-only service-view, process-view af det samme
+Journal-objekt og en separat passiv `JournalServiceManager`. Journal-manageren registreres ikke og giver kun adgang
+til root og refresh gennem et package-private admin-view; almindelige `JournalService`-consumers kan ikke udlede
+administrationsadgangen.
+
 Den package-private `NenjimRegistryServiceAdmin` er managerens interne mutationsadgang. Den må ikke gøres public,
 fordi almindelige consumers ellers kunne caste deres Registry-service til mutationsinterfacet og bryde det
 read-only service contract. Registration starter ikke et objekt, og Registry'et forbliver internt åbent for senere
@@ -214,12 +226,13 @@ registration efter startup.
 
 Applikationen ejer sine konkrete valg og sin activation. Tickerens initiale configuration vælger eksplicit
 `assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
-inaktiv. Hub'en starter Registry-processen først og registrerer den som `nenjim.registry.service`. Derefter starter
-Hub'en kun den nuværende eksplicitte, dependency-safe liste: Ticker, Production Evelyn, Test Evelyn, Production IOU
-Burner og Mission Control. Alarmen og øvrige tidligere udkommenterede applikationer bliver ikke automatisk
-aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en process-ID'et i et immutable, ordered snapshot; et
-fejlet start bliver ikke registreret, og listen lover ikke fortsat health eller liveness. Startup er fail-fast og kan
-kun forsøges én gang uden generic rollback.
+inaktiv. Hub'en starter Registry-processen først og registrerer den som `nenjim.registry.service`. Journal-servicen
+registreres dernæst som `nenjim.journal.service`, startes som den anden proces og skal være fuldt initialiseret, før
+business graph'en fortsætter. Derefter starter Hub'en kun den nuværende eksplicitte, dependency-safe liste: Ticker,
+Production Evelyn, Test Evelyn, Production IOU Burner og Mission Control. Alarmen og øvrige tidligere
+udkommenterede applikationer bliver ikke automatisk aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en
+process-ID'et i et immutable, ordered snapshot; et fejlet start bliver ikke registreret, og listen lover ikke fortsat
+health eller liveness. Startup er fail-fast og kan kun forsøges én gang uden generic rollback.
 
 `com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap. `Main.main(...)` konstruerer `NenjimHubImpl` gennem
 det globale `NenjimHub`-interface og kalder `start()` præcis én gang. Hub'en ejer også det eksisterende online point