security: tracking.db exposes full command history and project directory structure

Problem

RTK stores command execution history in a SQLite database at `~/.local/share/rtk/tracking.db` (or platform equivalent). This database contains:

```sql CREATE TABLE commands ( id INTEGER PRIMARY KEY, timestamp TEXT NOT NULL, original_cmd TEXT NOT NULL, -- Full command including arguments rtk_cmd TEXT NOT NULL, -- Rewritten command project_path TEXT DEFAULT '', -- Full project directory path input_tokens INTEGER NOT NULL, output_tokens INTEGER NOT NULL, saved_tokens INTEGER NOT NULL, savings_pct REAL NOT NULL, exec_time_ms INTEGER DEFAULT 0 ); ```

(see `src/core/tracking.rs` lines 263-289)

What this exposes

If the database file is accessed (via backup, sync, or exfiltration):

1. Full command history: Every command executed through RTK with timestamps
2. Project structure: `project_path` reveals all directories where RTK was used
3. Work patterns: Command frequency reveals when the developer works and what they're building
4. 90-day retention: Data persists for 3 months before auto-cleanup (line 389: `DEFAULT_HISTORY_DAYS`)

Additional concern: parse_failures table

```sql CREATE TABLE parse_failures ( id INTEGER PRIMARY KEY, timestamp TEXT NOT NULL, raw_command TEXT NOT NULL, -- Full failed command error_message TEXT NOT NULL, fallback_succeeded INTEGER NOT NULL DEFAULT 0 ); ```

This stores commands that failed to parse -- potentially including sensitive commands that the user did not intend to log.

Proposed mitigations

1. Add WAL mode encryption (long term)

SQLite supports encryption via SQLCipher. Adding optional encryption would protect the database at rest.

2. Reduce retention period

Make the 90-day retention configurable and consider a shorter default (e.g., 30 days).

3. Hash project paths

Instead of storing full `project_path`, store a salted hash. This preserves the ability to do project-scoped queries (`rtk gain --project`) without exposing directory names.

4. Add a `--no-track` flag

Allow users to execute commands without recording them in the database:

```bash rtk --no-track git status ```

5. Document the database location and contents

Add a section to the README/SECURITY.md explaining what is stored, where, and for how long.

Acceptance criteria

• Users can opt out of tracking per-command
• Project paths are hashed or configurable
• Retention period is documented and configurable
• Database location is documented in privacy section