Add initial implementation of gitea-mcp-forward-auth microservice

- Create build and release workflows for CI/CD
- Implement Dockerfile for multi-stage builds
- Add core authentication logic with token validation
- Include HTTP handler for authorization checks
- Set up Kubernetes deployment and service manifests
- Update README with usage instructions and configuration details

README.md

@@ -1,3 +1,107 @@
 # gitea-mcp-forward-auth
 
-Traefik-ForwardAuth-kompatiblen Microservice baut, der mehrere Bearer-Tokens aus einem gemounteten Secret validiert.
+Kleiner Go-basierter Traefik-ForwardAuth-Microservice, der Bearer-Tokens gegen eine konfigurierbare Menge gueltiger Tokens prueft.
+
+## Verhalten
+
+- Prueft `Authorization: Bearer <token>`.
+- Validiert Token gegen Tokens aus:
+	- `AUTH_PROXY_TOKENS_DIR` (jede Datei enthaelt genau einen Token), und/oder
+	- `AUTH_PROXY_TOKENS` (kommagetrennte Liste).
+- Antwortet mit:
+	- `200` (leer) bei gueltigem Token,
+	- `401` bei fehlendem/ungueltigem Header oder ungueltigem Token.
+- `GET /healthz` ist immer ohne Auth erreichbar.
+- Loggt jeden Auth-Versuch strukturiert, ohne Klartext-Token.
+
+## Sicherheitsaspekte
+
+- Token-Matching erfolgt auf Basis von SHA-256-Digests mit `crypto/subtle.ConstantTimeCompare`.
+- Token werden nie im Klartext geloggt; es wird nur ein kurzer Fingerprint (`sha256:...`) geloggt.
+- Start bricht fail-fast ab, wenn keine gueltigen Tokens geladen werden konnten.
+
+## Konfiguration (ENV)
+
+- `AUTH_PROXY_LISTEN_ADDR`
+	- Default: `:8080`
+	- Beispiel: `:8080`
+- `AUTH_PROXY_TOKENS_DIR`
+	- Optional
+	- Pfad auf ein Verzeichnis, in dem jede Datei einen Token enthaelt (z. B. Kubernetes Secret Volume)
+- `AUTH_PROXY_TOKENS`
+	- Optional
+	- Kommagetrennte Tokenliste, z. B. `token-a,token-b`
+- `AUTH_PROXY_LOG_LEVEL`
+	- Default: `info`
+	- Werte wie `debug`, `info`, `warn`, `error`
+
+Hinweis: Es muss mindestens eine Tokenquelle (`AUTH_PROXY_TOKENS_DIR` oder `AUTH_PROXY_TOKENS`) konfiguriert sein.
+
+## Lokal bauen und starten
+
+```bash
+go test ./... -v
+go vet ./...
+go build ./cmd/authproxy
+
+AUTH_PROXY_TOKENS="my-token-1,my-token-2" \
+AUTH_PROXY_LISTEN_ADDR=":8080" \
+go run ./cmd/authproxy
+```
+
+## Beispielaufrufe
+
+```bash
+# healthcheck (ohne Auth)
+curl -i http://localhost:8080/healthz
+
+# fehlender Token -> 401
+curl -i http://localhost:8080/
+
+# ungueltiger Token -> 401
+curl -i -H "Authorization: Bearer wrong" http://localhost:8080/
+
+# gueltiger Token -> 200
+curl -i -H "Authorization: Bearer my-token-1" http://localhost:8080/
+```
+
+## Docker
+
+Das Projekt enthaelt ein Multi-Stage-Dockerfile mit statisch gelinktem Binary (`CGO_ENABLED=0`) und non-root Runtime auf Distroless.
+
+```bash
+docker build -t gitea-mcp-auth-proxy:dev .
+docker run --rm -p 8080:8080 \
+	-e AUTH_PROXY_TOKENS="my-token-1,my-token-2" \
+	gitea-mcp-auth-proxy:dev
+```
+
+## CI/CD (Gitea Actions)
+
+- Build-Workflow: `.gitea/workflows/build.yaml`
+	- Push auf beliebige Branches
+	- `go vet`, `go test`, `go build`
+	- Kein Registry-Push
+- Release-Workflow: `.gitea/workflows/release.yaml`
+	- Trigger auf Tags `v*.*.*`
+	- Buildx-Remote-Builder und Push in Registry
+	- `latest` nur fuer stabile Tags `vX.Y.Z`
+	- Pre-Releases (z. B. `v1.2.3-rc1`) werden nicht als `latest` markiert
+
+Wichtig: Dieses Repository baut und pusht nur Images. Das eigentliche Kubernetes-Deployment erfolgt separat ueber FluxCD Image Automation in einem anderen Repository.
+
+## Kubernetes-Referenzmanifeste
+
+Referenzbeispiele fuer lokale Verifikation liegen unter:
+
+- `deploy/k3s/deployment.yaml`
+- `deploy/k3s/service.yaml`
+
+Diese Manifeste sind bewusst minimal und nicht als produktive FluxCD-Quelle gedacht.
+
+## Annahmen
+
+- Annahme: Go-Version ist `1.24` (aktuelle stabile Version zum Implementierungszeitpunkt muss ggf. angepasst werden).
+- Annahme: Release-Build pusht initial nur `linux/amd64`.
+- Annahme: Remote BuildKit ist im Runner-Netz unter `tcp://<default-gateway>:1234` erreichbar.
+- Annahme: Registry-Pfad ist `gitea.nehmer.net/torben/gitea-mcp-auth-proxy`.