Correct an entry date, and stop returns without an absence

Three things, all from the same screenshot.

The entry date can now be corrected. The Eintritt entry gets an edit
button — date only, no delete, because it is the start of the timeline
and a person without one has no beginning. Unlike every other entry it
needs no recorded before-values: the old date is on the employee row, so
this works on rows written long before any of this existed, which is
exactly the case that matters.

What hangs off that date is checked: no other event may precede it, exit
and absence start may not fall before it, and the first position
assignment moves with it — left behind it would leave days of employment
with no post, or a post with nobody in it. Someone already working
cannot be given a future entry date either; without that check a person
who has been here for years could be turned into a planned entry, and
the status derivation would agree.

That last rule came out of the rehearsal finding a hole: my first probe
picked a person with no other history rows, so the "nothing may precede
it" check had nothing to compare against and a date in 2099 sailed
through.

Second, the screenshot showed two returns from one absence, and the data
confirmed it: one person with two Rückkehr entries and a third still
scheduled, recorded while they were long since active. record_karenz_
return never checked that there was an absence to return from. Now it
does, and it refuses a second scheduled return — which would have
silently overwritten the first on its effective date.

Third, the history is filterable: upcoming versus done, a date range,
and the event types that actually occur in that file. The count of
upcoming items shows without filtering, because "what is coming" is the
usual reason to open the tab at all.

Still not deletable: Versetzung, Beförderung, Austritt, Wiedereintritt,
Reorganisation. Undoing those means restoring position assignments, and
that deserves its own step rather than being tacked onto this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

lib/history.ts

@@ -86,6 +86,21 @@ export function darfKorrigiertWerden(eintrag: Eintrag, heute: string, alle: Eint
   return { erlaubt: true };
 }
 
+/**
+ * Bearbeiten ist weiter gefasst als Löschen.
+ *
+ * Der Eintritt lässt sich nicht löschen — er ist der Anfang der Zeitleiste,
+ * und ohne ihn hätte die Person keinen. Sein **Datum** kann aber falsch
+ * erfasst sein, und dann hängt daran mehr als eine Zahl: die erste
+ * Planstellenbesetzung, der frühestmögliche Zeitpunkt jedes weiteren
+ * Ereignisses, die Zugehörigkeit. Die Datenbank prüft das alles beim Ändern;
+ * hier geht es nur darum, den Knopf überhaupt anzubieten.
+ */
+export function darfBearbeitetWerden(eintrag: Eintrag, heute: string, alle: Eintrag[] = []): KorrekturUrteil {
+  if (eintrag.event_type === "Eintritt") return { erlaubt: true };
+  return darfKorrigiertWerden(eintrag, heute, alle);
+}
+
 /** Später im Sinne der Anzeige: erst das Datum, dann die Erfassungszeit. */
 function spaeter(a: Eintrag, b: Eintrag): boolean {
   if (a.event_date !== b.event_date) return a.event_date > b.event_date;