Inbetriebnahme auf Prod: Checkliste und zwei Umgebungsdateien

Die Unit las bisher nur p2.env. Auf Prod steht die Datenbankverbindung
schon in ~/.config/wurzelwerk/database.env und gehoert Phase 1 mit; die
Unit liest jetzt beide, database.env zuerst. p2.env kann DATABASE_URL
ueberschreiben, falls database.env auf 127.0.0.1 zeigt - aus dem
Container heraus laeuft das ins Leere, dort muss
host.containers.internal stehen.

deploy/INBETRIEBNAHME.md haelt die Reihenfolge fest. Zwei Schritte darin
sind nicht offensichtlich und beide teuer, wenn man sie auslaesst:

  lexikon.py --laden   akteure.py liest aus den Tabellen, nicht aus den
                       JSON-Dateien. Ohne diesen Schritt laeuft Modul 4
                       durch und loest nichts auf, ohne zu scheitern.
  Erstbestand von Hand Der erste Lauf laedt 2,2 GB Modellgewichte und
                       kodiert den gesamten Korpus, ~17 min je 5000
                       Items. Aus dem Timer heraus liefe er in
                       TimeoutStartSec=1800.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NupWEBPzsyohVPG47HsTz8

deploy/wurzelwerk-p2.service

@@ -15,7 +15,16 @@ After=postgres.service
 
 [Service]
 Type=oneshot
-EnvironmentFile=%h/.config/wurzelwerk/p2.env
+# Zwei Dateien, in dieser Reihenfolge. database.env haelt die
+# Datenbankverbindung und gehoert nicht Phase 2 allein - sie steht auf Prod
+# schon da und wird hier nur mitgelesen, nicht angefasst. p2.env traegt, was
+# nur Phase 2 angeht; wird dort DATABASE_URL noch einmal gesetzt, gewinnt sie,
+# weil systemd spaetere Dateien spaeter liest.
+#
+# Beide muessen aus dem Container heraus aufloesbar sein: der Rechnername in
+# DATABASE_URL darf nicht 127.0.0.1 sein, sondern host.containers.internal.
+EnvironmentFile=%h/.config/wurzelwerk/database.env
+EnvironmentFile=-%h/.config/wurzelwerk/p2.env
 TimeoutStartSec=1800
 ExecStart=/usr/bin/podman run --rm \
     --name wurzelwerk-p2-lauf \