Honor tracking.enabled and history_days config

Summary

tracking.enabled and tracking.history_days are exposed in config/docs, but the v0.39.0 tracking write path appears to ignore both. database_path is honored; the enable flag and retention duration are not.

This is a local privacy/control hardening issue, not an accusation of malware.

Version / tag / commit

• Tag: v0.39.0
• Commit: 2fbc7514f6964acabcfac65501b8bb6b525e3aa8

Evidence

Config exposes tracking controls:

• src/core/config.rs:34-40 defines TrackingConfig { enabled, history_days, database_path }.
• src/core/config.rs:42-49 defaults enabled = true and history_days = DEFAULT_HISTORY_DAYS.
• docs/guide/getting-started/configuration.md:25-28 documents [tracking] enabled = true, history_days = 90, and database_path.

The tracking write/retention path does not appear to use enabled or history_days:

• src/core/tracking.rs:402-435 always inserts command records into commands.
• src/core/tracking.rs:465-483 always inserts parse failure records into parse_failures.
• src/core/tracking.rs:439-449 uses DEFAULT_HISTORY_DAYS directly for cleanup rather than config.tracking.history_days.
• src/core/tracking.rs:1220-1235 reads config only for tracking.database_path; no enabled or history_days handling appears there.
• src/core/tracking.rs:1356-1397 TimedExecution::track and track_passthrough instantiate Tracker::new() and record without checking config.

The data being controlled is privacy-relevant local history:

• src/core/tracking.rs:263-318 creates commands(original_cmd, rtk_cmd, project_path, ...) and parse_failures(raw_command, error_message, ...).
• src/core/tracking.rs:417-426 records the canonical current project path with each command.

Duplicate search performed:

• gh issue list -R rtk-ai/rtk --search "tracking.enabled history_days ignored"
• gh issue list -R rtk-ai/rtk --search "tracking config disable command history"

Only broad security issue #640 appeared; no focused duplicate was found.

Impact

A user who sets:

[tracking]
enabled = false
history_days = 7

would reasonably expect local command history to stop and retention to shorten. In v0.39.0, static source review indicates command history and parse failures are still written, and cleanup still uses the compile-time 90-day default.

Verification steps

1. Inspect src/core/config.rs for TrackingConfig.
2. Inspect src/core/tracking.rs record and cleanup paths.
3. Confirm database_path is read but enabled and history_days are not applied before inserting records or deleting old rows.

Suggested mitigation

• Honor tracking.enabled = false by making tracking writes no-op before opening/inserting into the DB, or by returning a disabled tracker state.
• Use config.tracking.history_days in cleanup instead of DEFAULT_HISTORY_DAYS.
• Add regression tests for disabled tracking and custom retention.
• Clarify docs if any fields are intentionally deprecated or unsupported.