fix: use absolute path for dev DATA_DIR default, clarify env docs (#46)

Closes #45.

## Problem

1. The README didn't clearly explain what `WEBHOOKER_ENVIRONMENT=dev` vs `prod` actually changes.
2. The dev-mode default for `DATA_DIR` was `./data` — a relative path whose meaning depends on the working directory. There's no reason to use a relative path even in development.

## Changes

### Code (`internal/config/config.go`)

- Replace the dev default `DATA_DIR` from `./data` to `$XDG_DATA_HOME/webhooker` (falling back to `$HOME/.local/share/webhooker`). This follows the XDG Base Directory Specification and ensures the data directory is always an absolute path regardless of the working directory.
- Add `devDataDir()` helper that resolves the XDG path, with a `/tmp/webhooker` last-resort fallback if `$HOME` can't be determined.

### Tests (`internal/config/config_test.go`)

- `TestDevDataDir`: verifies XDG_DATA_HOME is respected, HOME fallback works, and the result is always absolute.
- `TestDevDefaultDataDirIsAbsolute`: integration test that creates a full Config via fx and asserts the dev default DataDir is absolute.

### README

- Add a table documenting exactly what `dev` vs `prod` changes: DATA_DIR default, CORS policy, and session cookie Secure flag.
- Clarify that log format and security headers are independent of the environment setting.
- Update the DATA_DIR default in the configuration variable table.

Co-authored-by: clawbot <clawbot@eeqj.de>
Co-authored-by: user <user@Mac.lan guest wan>
Reviewed-on: #46
Co-authored-by: clawbot <clawbot@noreply.example.org>
Co-committed-by: clawbot <clawbot@noreply.example.org>

README.md

@@ -55,13 +55,22 @@ you can place variables in a `.env` file in the project root (loaded
 automatically via `godotenv/autoload`).
 
 The environment is selected by setting `WEBHOOKER_ENVIRONMENT` to `dev`
-or `prod` (default: `dev`).
+or `prod` (default: `dev`). The setting controls several behaviors:
+
+| Behavior              | `dev`                            | `prod`                          |
+| --------------------- | -------------------------------- | ------------------------------- |
+| CORS                  | Allows any origin (`*`)          | Disabled (no-op)                |
+| Session cookie Secure | `false` (works over plain HTTP)  | `true` (requires HTTPS)         |
+
+All other differences (log format, security headers, etc.) are
+independent of the environment setting — log format is determined by
+TTY detection, and security headers are always applied.
 
 | Variable                | Description                         | Default  |
 | ----------------------- | ----------------------------------- | -------- |
 | `WEBHOOKER_ENVIRONMENT` | `dev` or `prod`                     | `dev`    |
 | `PORT`                  | HTTP listen port                    | `8080`   |
-| `DATA_DIR`              | Directory for all SQLite databases  | `./data` (dev) / `/data` (prod) |
+| `DATA_DIR`              | Directory for all SQLite databases  | `/var/lib/webhooker` |
 | `DEBUG`                 | Enable debug logging                | `false`  |
 | `METRICS_USERNAME`      | Basic auth username for `/metrics`  | `""`     |
 | `METRICS_PASSWORD`      | Basic auth password for `/metrics`  | `""`     |
@@ -80,16 +89,16 @@ is only displayed once.
 ```bash
 docker run -d \
   -p 8080:8080 \
-  -v /path/to/data:/data \
+  -v /path/to/data:/var/lib/webhooker \
   -e WEBHOOKER_ENVIRONMENT=prod \
   webhooker:latest
 ```
 
 The container runs as a non-root user (`webhooker`, UID 1000), exposes
 port 8080, and includes a health check against
-`/.well-known/healthcheck`. The `/data` volume holds all SQLite
-databases: the main application database (`webhooker.db`) and the
-per-webhook event databases (`events-{uuid}.db`). Mount this as a
+`/.well-known/healthcheck`. The `/var/lib/webhooker` volume holds all
+SQLite databases: the main application database (`webhooker.db`) and
+the per-webhook event databases (`events-{uuid}.db`). Mount this as a
 persistent volume to preserve data across container restarts.
 
 ## Rationale
@@ -855,8 +864,8 @@ The Dockerfile uses a multi-stage build:
    golangci-lint, downloads dependencies, copies source, runs `make
    check` (format verification, linting, tests, compilation).
 2. **Runtime stage** (`alpine:3.21`) — copies the binary, creates the
-   `/data` directory for all SQLite databases, runs as non-root user,
-   exposes port 8080, includes a health check.
+   `/var/lib/webhooker` directory for all SQLite databases, runs as
+   non-root user, exposes port 8080, includes a health check.
 
 The builder uses Debian rather than Alpine because GORM's SQLite
 dialect pulls in CGO-dependent headers at compile time. The runtime