1.1.0 — compatibility workflow, database install, calibration CLI, update check

BatteryControl 1.1.0

Surface-parity and evidence-workflow release on the 1.0.2 base. No new
privileged mechanisms — the daemon still owns every hardware operation, and
unknown firmware stays read-only.

Compatibility reports, end to end

The report that feeds the compatibility database used to require running the
daemon binary by hand. Now there are three ways to get the identical JSON,
one shared generator:

• batterycontrol compatibility --report
• Diagnostics → Export Compatibility Report… in the app
• the original sudo com.batterycontrol.daemon --export-compat-report <path>

It contains your chip, model identifier, macOS and firmware builds, and the
SMC control-key signature. No serial numbers, no UUIDs, no usernames — a
privacy gate refuses to emit PII-shaped keys. A new GitHub issue template
mirrors the JSON fields, so a report lands ready to review.

Database install without an app update

When a new Mac gets verified, you shouldn't have to wait for the next app
release to be recognized. Install a reviewed database directly:

batterycontrol database install compatibility.json

or Settings → Compatibility Database → Install Database File…. The
privileged daemon validates the whole payload (schema, per-profile structure,
evidence requirements), writes the root-owned file atomically, activates it
in-process, and re-classifies the machine. Bad payloads are rejected with the
specific reason — schema mismatch, empty key sets, evidence missing.

The boundary is unchanged: a database entry broadens recognition only. Your
machine's hardware is still probed at runtime and every write is still
verified by readback before anything reports as active.

Calibration from the terminal

batterycontrol calibration status | start | cancel — the same guided cycle
the GUI runs (discharge to 20% → charge to 100% → hold 3 hours → drop to your
limit). The daemon owns the sequence and its safety gates; the CLI adds no
validation of its own.

Update check (passive)

A daily query to GitHub Releases, shown in Settings with a link when a newer
version exists (batterycontrol update-check works from the terminal too).
Default on, with a setting to turn it off entirely — disabling stops all
update-related requests. Nothing is ever downloaded or installed
automatically; in-place upgrades are exactly what the 1.0.2 stale-process
work made survivable, and updating remains a deliberate user action.

Native Charge Limit on macOS 26.4+ — documented, not claimed

The ownership model (BatteryControl vs Apple's built-in limit) stays
code-tested only. The physical test plan for a real 26.4+ machine now ships
at Docs/NativeChargeLimitTestPlan.md. Until someone runs it, the daemon
reports Apple's limit state as "could not be read" rather than guessing.

Validation

• 267 tests passing (23 new), zero compiler warnings, Release build clean
• Verified M3 profile (Mac15,13, mBoot-20457.1.29, macOS 15.8) re-validated
  on the shipping binaries: report emitted with the live signature, bad
  database rejected, shipped database installed, 80/70 limit Active and
  hardware-verified throughout
• Physical validation remains exactly one configuration; everything else is
  capability-tested. Compatibility reports are how that changes.

Fixed

• Version mismatch after a pkg upgrade now resolves through the app's
  existing Repair Helper flow (the pkg replaces the app; Repair Helper
  replaces the installed daemon) — validated end to end this release.

SHA-256: see SHA256SUMS in the assets. GUI pkg contains app + daemon +
CLI; the CLI-only pkg contains no daemon.