AlDente 1.38 still writes ~0.5 GB/day to the local statistics database after #1256 partial fix

**MacBook (please complete the following information):**
- MacBook Model: MacBook Pro (Mac17,9), Apple M5 Pro, 24 GB RAM
- macOS Version: macOS 26.5.2 (25F84)
- Charger Model: AC power connected; macOS did not expose the charger model in `system_profiler`
- Charging Cable: Not relevant to the observed background database writes
- AlDente Pro or AlDente Free: AlDente Pro
- AlDente Version: 1.38 (build 95)
- Settings: AlDente was running normally in the background; the dashboard was not being actively used during the measurement. Battery was at 83%, AC attached, not charging.
- Debug file: Not attached. The behavior is reproducible with Activity Monitor and the process I/O counters below.
- External Monitor connected: Not part of this test
- MacBook used in Clamshell Mode: No

## Describe the bug

AlDente 1.38 continues to write approximately **0.5 GB per day** while running in the background. The writes appear to be associated with the local battery statistics database:

```
~/Library/Preferences/com.apphousekitchen.aldente-pro_stats.sqlite3
```

This is not file growth: the database is only about 2.5 MB. It is repeated rewriting/journaling of a small database.

This report follows the partial disk-usage improvement made in AlDente 1.31 and the still-open reports in #1256. The behavior remains reproducible on the current 1.38 release.

## Measurements

After approximately 14.7 days of uptime, Activity Monitor reported about **7.24 GB written** by the AlDente process.

A 60-second measurement using macOS `proc_pid_rusage(..., RUSAGE_INFO_V4, ...)` produced:

```
written_before=7245955072
written_after=7246299136
written_delta=344064
read_delta=16384
```

That is:

- 344,064 bytes written per minute during the sampled interval
- approximately 495 MB/day
- approximately 181 GB/year if the Mac remains awake continuously

A preceding 30-second sample showed 0 bytes written, so the writes are bursty/periodic rather than a constant stream.

The database observations during the same investigation were:

```
Path:
~/Library/Preferences/com.apphousekitchen.aldente-pro_stats.sqlite3

Size:
2,523,136 bytes

Observed modification timestamps:
2026-08-01 10:31:33
2026-08-01 10:33:33
```

The AlDente process held this database open directly (file descriptor 12). Its WebKit/HTTP cache WAL files were unchanged during the test, while the statistics database modification time advanced.

AlDente also loads SQLCipher, so encrypted SQLite transaction/journal behavior may be contributing to the write amplification. This is an inference from the loaded framework and open file; the exact transaction strategy cannot be determined from outside the closed-source application.

## To Reproduce

1. Start AlDente 1.38 and leave it running normally in the menu bar.
2. Close or leave the dashboard inactive.
3. In Activity Monitor, open the Disk tab and note AlDente's "Bytes Written" value.
4. Leave the Mac awake for several minutes and observe the value again.
5. Alternatively, measure `ri_diskio_byteswritten` for the AlDente PID over repeated 60-second windows.
6. Observe the modification time of `com.apphousekitchen.aldente-pro_stats.sqlite3`.

The writes occur even when the user is not interacting with AlDente.

## Expected behavior

Background charge limiting should not require roughly 0.5 GB/day of repeated writes to a 2.5 MB statistics database.

Possible improvements:

- Keep samples in memory and batch database commits at a much lower frequency.
- Allow a reasonable amount of recent statistics to be lost on a crash instead of synchronously persisting every small update.
- Review the SQLite/SQLCipher journal mode, checkpointing, and transaction size.
- Avoid rewriting unchanged battery values.
- Add a setting to disable local statistics collection entirely while preserving the core charge limiter.
- Add a low-frequency/lightweight mode without dashboard statistics.
- Add a regression test or benchmark for bytes written per hour while idle.

A target of a few megabytes per day, or less, would be more proportionate for this type of menu bar utility.

## Related issues and previous work

- #1256 - original excessive disk-write report. AlDente 1.31 included a partial reduction, but later users continued to report multiple GB per week. The issue is currently reopened.
- #1702 - idle energy/resource usage.
- #1746 - request for a lightweight mode without statistics, SQLite databases, or frequent polling.

The maintainer has already acknowledged in #1256 that the activity is mainly related to the local statistics database, that previous updates did not fully solve it, and that larger improvements were planned for a future release after 1.37. AlDente 1.38 release notes do not mention a disk-write fix, and the measurements above show that the issue is still present.

## Impact

At this measured rate, AlDente alone is unlikely to create an immediate SSD-endurance risk. The problem is the unnecessary background I/O, energy use, and write amplification relative to the small amount of useful statistics being stored. These writes also add to the cumulative load from browsers, development tools, swap, indexing, and other always-running applications.

The payload names only ~/Library/Preferences/com.apphousekitchen.aldente-pro_stats.sqlite3, not a source file or test. First reproduce the idle writes with Activity Monitor or repeated proc_pid_rusage measurements and compare the database modification time, then inspect the statistics persistence path and related work in #1256. Done means background operation no longer produces roughly 0.5 GB/day of database-related writes while charge limiting remains functional.

Escrita pelo modelo de indexação a partir do texto da issue.