docs: record the measured storage cost and the new crate boundary

Updates the ADR log, architecture, limitations, perf table and README to match
what now exists, rather than what was expected.

**The perf number was wrong and is now honest.** The M0 figure of 0.279 MB
excluded SQLite entirely — the placeholder binary never referenced the crate, so
dead-code elimination dropped it. With the daemon actually opening a database it
is **1.364 MB**, of which bundled SQLite is ~1.1 MB. That is 1.1 MB of the 5 MB
budget spoken for, leaving 3.8 MB for D-Bus, X11 and a UI toolkit.

This is the first number that makes the section 5 budget feel like a budget
rather than a formality, and it turns ADR-4's bundled-vs-system-linked choice
into a real trade-off with a measured price on both sides.

- ADR-4 marked accepted and implemented, with that trade-off left open.
- ARCHITECTURE.md documents why `blocker-storage` is a sibling crate and not a
  submodule: the dependency direction is what keeps the zero-dependency purity
  proof automatic rather than a grep someone can route around.
- LIMITATIONS.md drops the stale "storage has no I/O" shortfall and records the
  bundled-vs-system question instead, plus the fact that `LockState` still always
  evaluates to Normal.
- README status table and layout updated.

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/DECISIONS.md

@@ -25,7 +25,7 @@ which parts to trust.
 | [1](#adr-1) | Rust for core and desktop, Kotlin for the Android shell | Accepted |
 | [2](#adr-2) | One shared core; the engine is a pure function | Accepted |
 | [3](#adr-3) | Event-driven with `next_wakeup`, never polling | Accepted |
-| [4](#adr-4) | SQLite via rusqlite, bundled | Proposed |
+| [4](#adr-4) | SQLite via rusqlite, in its own crate | Accepted, one trade-off open |
 | [5](#adr-5) | uniffi for core-to-Kotlin bindings | Proposed |
 | [6](#adr-6) | Desktop UI toolkit — Slint vs egui | **Proposed, needs owner** |
 | [7](#adr-7) | Desktop website blocking mechanism | **Accepted — owner chose extension** |
@@ -108,24 +108,46 @@ it is supposed to start blocking.
 ---
 
 <a id="adr-4"></a>
-## ADR-4: SQLite via rusqlite, bundled
+## ADR-4: SQLite via rusqlite
 
-**Status:** Proposed — dependency not yet added
+**Status:** Accepted and implemented, with one trade-off still open
 
 **Context.** Section 3 specifies `rusqlite` with bundled SQLite. Section 1.5.3
 requires lock and Strict state to live in the core database rather than in
 editable plaintext config.
 
-**Decision.** `rusqlite` with `bundled`, storing schedules, lock state, and usage
-counters in one file.
+**Decision.** `rusqlite` with `bundled`, in a **separate `blocker-storage` crate**
+that depends on `blocker-core`, never the reverse.
 
-**Consequences.** The schema is written and reviewed in
-`core/src/storage.rs` before the crate is added, so it can be reviewed as text.
-Bundling compiles SQLite from source, which costs build time and binary size but
-removes a system dependency — a real consideration on the machines this ships to.
+**Why the separate crate.** The purity contract says the engine does no I/O, and
+`tests/purity.rs` enforces that mechanically by failing if `blocker-core` has any
+dependency at all. Putting `rusqlite` in `blocker-core` would have forced that
+check to degrade into a source-text grep — something a careful developer can route
+around, and something nobody reads in six months. Splitting keeps the check
+automatic.
 
-The binary-size cost has not yet been measured against the 5 MB budget. That is
-an open item, not a settled fact.
+Both crates sit in the same layer of the section 2 diagram: storage is shared by
+every platform and contains no platform code. This is a refinement that makes the
+guarantee checkable, not an architectural departure.
+
+**Measured consequences.**
+
+- Bundled SQLite costs **~1.1 MB** of the 5 MB stripped daemon budget (1.364 MB
+  total, from 0.279 MB without it). That leaves 3.8 MB for D-Bus, X11 and a UI
+  toolkit — a real margin, not a comfortable one.
+- The build compiles SQLite from C source, which is a noticeable first-build cost.
+- System-linking would reclaim most of the 1.1 MB at the price of a runtime
+  dependency on the host's libsqlite3, and a schema-format mismatch that only
+  appears on a user's machine.
+
+**Still open:** bundled vs system-linked. Measured cost is now known; the decision
+is the owner's.
+
+**Schema notes.** Relational (`schedule_target`, `schedule_condition`) rather than
+JSON blobs in a text column, because target rows are queried by target and an
+index on a JSON string is not a plan. Serialisation is hand-written in
+`storage/src/codec.rs` — `serde` is not a section 3 dependency, and section 0 rule
+3 requires asking before adding one (ADR-13).
 
 ---