Add sync receipts naming which devices hold the case, plus a metered-data policy

[ChelseaKR]

What

After a sync, an organizer cannot answer "is this case safely on more than one device?" Add signed sync receipts: each successful merge writes a receipt (peer identity, case id, both heads, HLC watermark, transport) into the vault; habitable status and the app show "in sync with N devices as of ; last receipt from ", and a case held by one device only is flagged. Alongside it, a per-vault network policy (--metered, Wi-Fi only) that defers timestamp fetch and sync on metered links and shows the estimated bytes before a sync.

Why it matters

RR-07 ("you are in sync as of X; this case is on N devices") is the organizer-persona finding, and peer redundancy is the project's only backup story that does not involve a server. RR-13 is the data-cost transparency item for tenants on metered plans. Receipts are local and signed and never go to a relay, so metadata resistance (#288) is not weakened.

Scope

• A receipt record and signature in syncstate.py; status, the app, and the packet cover sheet (device count only; no identities in the packet).
• Policy in config.py; resolve and sync honour it; a byte estimate from delta size.
• EN/ES copy; the readability gate applies.

Out of scope

• Any server-side presence.
• Automatic sync scheduling.

Done when

• Two devices syncing produce matching receipts on both sides; a tampered receipt fails its signature check.
• A single-device case shows the redundancy warning; after one sync it clears.
• With --metered, resolve defers and reports what it deferred; nothing is fetched.

Pointers

• src/habitable/sync.py, src/habitable/syncstate.py, src/habitable/pairing.py, src/habitable/cli.py (status, resolve), docs/sync-protocol-v2.md
• docs/RESEARCH-ROADMAP.md (RR-07, RR-13); v2.x: metadata-resistant sync #288

Proposed with AI assistance.

[ChelseaKR]

Triage: partly done — both halves have real substrate on main; what is missing is the redundancy surface.

The premise needs correcting in two places. Verified on origin/main @ bf631af:

1. The metered-data policy is shipped. src/habitable/cli.py:126 defines dest="wifi_only" and cli.py:2162 acts on it; app/app.js:963 renders the state; app/i18n/en.json:90 and app/i18n/es.json:90 carry network_wifi_only ("Wi-Fi only (metered fetches off)" / "Solo Wi-Fi (descargas con datos desactivadas)"). tests/test_datacost.py is on main. The R-03/R-18/R-19 data-cost work landed; the branch roadmap/data-cost-and-storage-ux-r-03-r-18-r-19-8 is behind main for it.

2. Signed sync receipts already exist — as delivery receipts. src/habitable/vault.py:928 queue_sync_receipt, vault.py:936 pending_sync_receipts, vault.py:942 record_verified_sync_receipt, driven from sync.py:271-276, and both refuse a receipt from an unauthorized peer. Replay protection is there too (has_seen_sync_message / mark_sync_message_seen).

What is genuinely absent is the thing the organizer persona actually asked for: the redundancy answer. git grep -Ein 'in sync|devices|last receipt' origin/main -- src/habitable/cli.py app/i18n/en.json returns nothing. There is no "in sync with N devices as of <time>", no last-receipt display, and no single-device warning.

So this is a smaller, better-shaped piece of work than the issue implies: surface the receipt store that already exists, rather than build a receipt mechanism. Scope note for a builder — the existing receipts are per-message and peer-bound, so a device count derived from them must not count a peer that has never completed a merge, and a case that has synced once and not since must not read as currently redundant. That distinction (ever-synced vs. in-sync-now) is where this would go wrong, and it is the same absence-as-a-value class as #307/#309/#311.

Left open with that scope note rather than half-built. The metered half needs nothing further; consider narrowing the title to the receipts surface.

---

Triage pass against origin/main @ bf631af. Verdict only; nothing was changed. Prepared with AI assistance.

[ChelseaKR]

Measured: the deferred cover-sheet line is not blocked by the packet contract

PR #319 landed the sync-receipt half of this issue and left the packet cover sheet's device count out, on the ground that adding a field inside one of the seven additionalProperties: false objects in docs/packet-bundle.schema.json would need a packet_version decision. I measured that rather than inheriting it, and it does not apply here.

Method. Schema at main, jsonschema 4.26.0 / Draft 2020-12, throwaway venv outside the repo. tests/golden/packet-v4/bundle.json validated unmutated first so pre-existing errors are subtracted, then each candidate shape applied and the error set diffed.

shape	validates?
appendix.device_count: 2	yes
appendix.redundancy = {device_count, as_of, identities_included: false}	yes
top-level sync_redundancy = {device_count, as_of}	yes
(control) appendix.item_count: "two"	REJECTED — 'two' is not of type 'integer'

appendix is additionalProperties: true, and so is the document root. It is not one of the seven closed objects — those are artifact, relationship, custodyEntry, sensorSeries, workflowIntegrity, and links and integrity inside timelineEntryV3. The control confirms the validator can still refuse, so "accepted" here is a measurement rather than a validator that was never wired up.

appendix is also already where this kind of figure lives: item_count, timestamped_count, timeline_count, custody_bound_timeline_count, artifact_count, relationship_count. A device count is the same shape of fact, in the same place, and it validates today.

One thing worth pinning when it is built, because it is this project's dominant defect wearing a redundancy claim. device_count has three states, not two: N devices have acknowledged holding this case, no device has (the single-device warning status already prints), and no receipt exists yet, so nothing was counted. The third must not render as 0, which reads as "measured, and the answer is nobody" — the same distinction status_sync_alone already makes on the CLI. Carrying as_of alongside the count is what lets a reader tell a stale count from a current one, and the field is free since the object is open.

The scope note about identities still holds and is unaffected: a count is not an identity, and nothing here proposes putting peer fingerprints in the packet.

This is not the whole of #297 — the metered-data policy half is separate and also untouched by the schema question. Recording the measurement so the deferral does not outlive its reason.

Prepared with AI assistance; reviewed before submission.