docs: correct stale documentation and drop planning artifacts

The docs had drifted from the code and described things that never existed.

- architecture.md documented a QuitCommand class (quit/exit are aliases on
  MenuCommand) and a GameIO interface of read()/write(String); the real one is
  readLine() plus print(StyledText) with presentation hooks. Both corrected,
  along with the package diagram and the game-loop sketch.
- conventions.md listed a package tree missing save, menu, io.text and
  command.impl. Updated, including why MapLayout lives in game.
- data-structures.md claimed LinkedList was deliberately avoided (Pathfinder
  uses one for O(1) addFirst during path reconstruction), named the wrong queue
  for the Swing bridge, and listed an input history that was never built.
- Removed enhancement-ideas.md and implementation-status.md: a backlog and a
  phase tracker, neither of which documents the delivered project.

Also stop tracking the built jars. They still ship in the submission, but a
22 MB binary that changes on every build does not belong in git history.

Semesterprojekt/docs/data-structures.md

@@ -15,13 +15,16 @@ Bewusste Wahl jeder Collection — der Dozent bewertet das laut Aufgabenstellung
 | Spieler-Inventar | `LinkedHashMap<String, Item>` | O(1) |
 | Befehlsregistry | `HashMap<String, Command>` | O(1) |
 | NPC-Reaktionen | `HashMap<String, NpcReaction>` | O(1) |
-| Eingabehistorie (optional) | `ArrayDeque<String>` | O(1) Front/Back |
+| Besuchte Räume (für die Karte) | `LinkedHashSet<String>` | O(1) + Besuchsreihenfolge |
+| BFS-Queue (Pathfinder, MapLayout) | `ArrayDeque<Room>` | O(1) FIFO |
+| BFS-Pfadrekonstruktion | `LinkedList<Room>` | O(1) `addFirst` |
+| GUI-Eingabebrücke (EDT → Worker) | `LinkedBlockingQueue<String>` | blockierend, unbegrenzt |
 
 ## Begründungen im Detail
 
 ### `EnumMap<Direction, Room>` für Raum-Ausgänge
 
-- **Direction** ist Enum (`NORTH`, `SOUTH`, `EAST`, `WEST`, evtl. `UP`, `DOWN`)
+- **Direction** ist Enum (`NORTH`, `SOUTH`, `EAST`, `WEST`)
 - `EnumMap` ist array-backed, kein Hashing nötig → schneller und kompakter als `HashMap`
 - Iteration in Enum-Deklarationsreihenfolge (stabil)
 
@@ -49,11 +52,19 @@ Entscheidung "keine Stapel" (1 Item pro id) macht das Map-basierte Modell sauber
 - Entspricht dem expliziten Tipp aus der Aufgabenstellung
 - Vermeidet wachsendes `switch`-Statement
 
-### `ArrayDeque<String>` für Historie (optional)
+### `ArrayDeque<Room>` als BFS-Queue
 
-- Falls Up-Arrow in der GUI gewünscht oder Befehlsverlauf
-- `ArrayDeque` ist `LinkedList` praktisch immer überlegen (bessere Cache-Lokalität, weniger Overhead)
-- Beidseitige O(1)-Operationen
+- `Pathfinder` (Auto-Travel `go to <raum>`) und `MapLayout` (Karten-Layout) sind beides
+  Breitensuchen → brauchen eine **FIFO-Queue**
+- `ArrayDeque` ist die Standardwahl dafür: O(1) an beiden Enden, keine Node-Allokation
+  wie bei `LinkedList`, bessere Cache-Lokalität
+
+### `LinkedList<Room>` für die Pfadrekonstruktion
+
+Die eine Stelle, an der `LinkedList` die richtige Wahl ist (`Pathfinder`):
+Nach der BFS läuft man über `cameFrom` **rückwärts** vom Ziel zum Start und will den
+Pfad in Vorwärtsreihenfolge. `addFirst()` ist bei `LinkedList` O(1) — bei `ArrayList`
+wäre `add(0, x)` O(n), weil alles verschoben werden müsste.
 
 ## Bewusst NICHT gewählt
 
@@ -62,7 +73,7 @@ Entscheidung "keine Stapel" (1 Item pro id) macht das Map-basierte Modell sauber
 | `ArrayList<Item>` für Inventar | O(n)-Lookup, Duplikat-Handling nötig |
 | `HashMap<String, Item>` für Inventar | Anzeige-Reihenfolge instabil |
 | `TreeMap` irgendwo | Keine sortierte Iteration nötig, O(log n) ohne Nutzen |
-| `LinkedList` | `ArrayDeque` ist fast immer besser |
+| `LinkedList` als Queue | dafür ist `ArrayDeque` besser (s.o.) — als `addFirst`-Liste in der Pfadrekonstruktion aber sehr wohl genutzt |
 | `Vector` / `Hashtable` | Legacy, synchronisiert (nicht gebraucht), langsamer |
 | `Map<String, String>` für Exits in Domain | Direction sollte Enum sein, nicht String |
 
@@ -70,4 +81,9 @@ Entscheidung "keine Stapel" (1 Item pro id) macht das Map-basierte Modell sauber
 
 Single-threaded: Game-Loop liest, dispatcht, schreibt — keine parallelen Mutationen.
 
-**Ausnahme:** Bei Swing-GUI läuft Input über den Event-Dispatch-Thread, der Game-Loop in einem Worker-Thread. Hier kommt `BlockingQueue<String>` (`ArrayBlockingQueue` reicht) als Brücke ins Spiel — siehe [architecture.md](architecture.md).
+**Ausnahme:** Bei Swing-GUI läuft Input über den Event-Dispatch-Thread, der Game-Loop in
+einem Worker-Thread. Als Brücke dient eine `LinkedBlockingQueue<String>` (`SwingIO`):
+Der `JTextField`-ActionListener (EDT) legt die Zeile ab, der Worker blockiert in
+`take()`. Unbegrenzt statt `ArrayBlockingQueue`, weil es keine sinnvolle Obergrenze für
+getippte Zeilen gibt und ein volles `offer()` Eingaben verlieren würde — siehe
+[architecture.md](architecture.md).