feat(seed): mitgelieferte Vorlagen am Schluessel erkennen

Der Seed erkannte seine sieben Vorlagen am Namen. Wer eine umbenannte, bekam
beim naechsten Lauf eine zweite -- und der Schnellstart stand auf der
Geraeteseite doppelt.

Vorlage.seedSchluessel traegt die Kennung, eindeutig wo gesetzt (partieller
Index, weil eigene Vorlagen keinen tragen). Das Austauschformat kennt das Feld
als seedSchluessel; nicht als schluessel, wie das Issue plante, denn so heisst
dort schon das Feld einer Variablen.

Der Rueckfall auf den Namen bleibt, sonst bekaeme eine Installation von vor
diesem Feld beim ersten Lauf danach genau die Dubletten, die es verhindern
soll. Wird sie so gefunden, traegt der Seed den Schluessel nach -- an der
Entwicklungsdatenbank gefahren: sieben nachgetragen, nichts neu angelegt.

Der Import setzt den Schluessel nicht, auch nicht wenn das Dokument ihn
mitbringt, und der Export schreibt ihn nicht: eine eingespielte Kopie soll
nicht den Platz des Originals einnehmen.

Gegenprobe gefahren: ohne die Suche am Schluessel werden vier Tests rot.

Closes #32

CHANGELOG.md

@@ -24,6 +24,12 @@ und dieses Projekt folgt [Semantic Versioning](https://semver.org/lang/de/).
 
 ### Hinzugefügt
 
+- Mitgelieferte Vorlagen tragen einen **stabilen Schlüssel** (`seedSchluessel`). Der Seed erkennt
+  seine sieben Vorlagen daran statt am Namen — wer eine umbenannte, bekam vorher beim nächsten Lauf
+  eine zweite, samt doppeltem Schnellstart auf der Geräteseite. Eine bestehende Installation bekommt
+  den Schlüssel beim ersten Lauf danach nachgetragen, ohne Dubletten. Eine über den Import
+  eingespielte Kopie bekommt **keinen** Schlüssel: sie soll nicht den Platz des Originals einnehmen
+  (#021)
 - `pnpm pruefe:doku` vergleicht die Schranken-Befehle in `CLAUDE.md` und `README.md` und verlangt von
   beiden den LDAP-Container. Genau diese Abweichung war unbemerkt entstanden (#040)
 - Fünf Tests für den Healthcheck, darunter einer, der belegt, dass die Begründung ins Protokoll