chore: reset repo to clean template state

Remove all tg-bot-jetson project artefacts (session logs, filled
session-prompts F-01–F-07, ADRs 0002–0004). Reset ROADMAP.md board,
STATE.md, CONVENTIONS.md project section, manifests/requirements.md,
and metrics/efficiency.csv to blank template placeholders.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/adr/0002-python-telegram-bot-framework.md

@@ -1,15 +0,0 @@
-# 0002 — python-telegram-bot v21 als Bot-Framework
-
-- **Status:** accepted
-- **Kontext:** Das Projekt braucht ein Python-Telegram-Bot-Framework.
-  Alternativen: `aiogram`, `telebot` (pyTelegramBotAPI), `ntelegram`.
-- **Entscheidung:** `python-telegram-bot` v21 mit nativem `asyncio` und `httpx`
-  als HTTP-Client für den Modell-Connector. `uv` als Paketmanager.
-- **Gründe:**
-  - PTB v21 hat die breiteste Doku, Beispiel-Bibliothek und Community für Telegram.
-  - Asyncio-first: passt zum Streaming-Potenzial künftiger Modell-Antworten.
-  - `httpx` ist de-facto-Standard für async HTTP in Python 3.11+.
-  - `uv` ist schneller und reproduzierbarer als plain pip.
-- **Konsequenz:** Gesamte Codebasis ist async-first. PTB-Filter-System
-  (`filters.User`) eignet sich direkt für die Whitelist (F-03).
-  Keine Sync-Wrapper nötig.

docs/adr/0003-whitelist-env-var.md

@@ -1,16 +0,0 @@
-# 0003 — User-Whitelist via Umgebungsvariable
-
-- **Status:** accepted
-- **Kontext:** Nur ausgewählte Telegram-User-IDs dürfen den Bot nutzen.
-  Optionen: Datenbank, Config-Datei, Env-Var, hardcodiert.
-- **Entscheidung:** Env-Var `ALLOWED_USER_IDS` als komma-separierte Liste
-  ganzer Zahlen (z. B. `ALLOWED_USER_IDS=123456,789012`).
-  PTB-Filter `filters.User(user_ids=...)` erzwingt die Prüfung deklarativ.
-- **Gründe:**
-  - Kein Deployment-Artefakt für die Liste nötig — reicht für v1.
-  - Änderung ohne Code-Deploy: Service neu starten genügt.
-  - Keine persistente Zustandsverwaltung, kein Datenbankrisiko.
-  - Leicht in `.env`-Datei und Docker/systemd-Unit einzutragen.
-- **Konsequenz:** Für v2 (dynamisches Hinzufügen per Admin-Command) muss
-  ein Persistenz-Layer (SQLite o. ä.) ergänzt werden — das ist ein eigenes
-  Board-Item und ändert diese Entscheidung.

docs/adr/0004-modell-api-spike-first.md

@@ -1,18 +0,0 @@
-# 0004 — Modell-Connector gegen OpenAI-kompatible API, kein Spike nötig
-
-- **Status:** accepted (ersetzt: 2026-06-03, vorherige Version sah Spike vor)
-- **Kontext:** Der selbst gehostete Modell-Server (Jetson Orin Nano Super) ist
-  ein **externer Dienst** außerhalb dieses Repos. Das Backend (Ollama, llama.cpp,
-  vLLM o. ä.) ist Sache des Betreibers, nicht dieses Projekts.
-- **Entscheidung:** Der Connector (F-05) portiert gegen die **OpenAI Chat
-  Completions API** (`POST /v1/chat/completions`). Das ist der de-facto-Standard
-  für selbst gehostete Modelle. Die Basis-URL wird via Env-Var `MODEL_BASE_URL`
-  konfiguriert. Kein Spike nötig — die API-Spec ist bekannt und stabil.
-- **Gründe:**
-  - Ollama, llama.cpp-HTTP, vLLM und LiteLLM exponieren alle diese Schnittstelle.
-  - Der Connector funktioniert mit jedem Backend, das sich daran hält.
-  - Ein Spike wäre nur nötig, wenn das API-Format unbekannt wäre — das ist hier
-    nicht der Fall.
-- **Konsequenz:** Wenn der externe Server ein nicht-kompatibles Format hat,
-  ist das ein Ops-Problem, kein Code-Problem. F-05 dokumentiert das erwartete
-  Schema im Manifest (R-0006).