Residual security and reliability items from the #38 review

[jsconu]

Residual items from the security/code review (#38) that are not fixed, with why:

1. Passcode and "requests are never self-granted" are client-side gates. The paired kid device holds its own Firebase credentials, can read the passcode hash, and the "parent mode" rule has no passcode check (rules can't run PBKDF2). Fully fixing this needs a server (e.g. a Cloud Function that verifies the passcode with lockout and performs privileged writes), which the project deliberately doesn't have. Documented in the README and at the top of firestore.rules.
2. linkedDeviceUids self-add. Any signed-in device can add itself to another family's linkedDeviceUids if it knows the parent uid. Proposed redesign: per-device linkedDevices/{uid} docs created only through the pairing transaction.
3. Whole-list overwrite races in limit/allow-list edits (two editors overwrite each other) - would need field-level array ops or transactions.
4. Bedtime calls: Android may not consult call screening for numbers saved in Contacts (needs verifying on a device, possibly READ_CONTACTS); text muting depends on how each messaging app builds its notifications. Needs real-device testing.
5. Notification counts include re-posts of the same notification key (kid and parent counters).
6. First-app-after-unlock attribution depends on event ordering between USER_PRESENT and the first window event.
7. Clock rollback on the kid device can extend the temporary unlock / lockout windows; App Check isn't enabled.
8. Crashlytics collection is on by default (documented); the opt-in notification digest is stored in plaintext app prefs.

[jsconu]

Status after the follow-up work (commit "Issue #39: bind device linking to the pairing claim..."):

Fixed

• linkedDeviceUids self-add - a kid device now links itself through parents/{parent}/linkedDevices/{deviceUid}, which the rules only allow in the same transaction that claims that parent's live pairing code (getAfter on the code doc). Devices can no longer write the old array at all (it is still honored for devices paired earlier). Emulator tests: a stranger can't link itself by either path; pairing leaves a linked-device doc the parent can see. Needs the updated firebase/firestore.rules published.
• Whole-list overwrite races - blocked domains, always-allowed apps and contacts are now edited one entry at a time (arrayUnion/arrayRemove) and per-app limits by nested merge, on Android and iOS, so two editors can't silently undo each other.
• Notification re-posts counted twice - identical re-posts of the same notification (same key, same title/text) are no longer counted on either app; a genuinely new message still counts.

Still open (deliberately or blocked)

1. Passcode and "requests are never self-granted" are client-side gates - closing that needs a server.
2. Call screening may skip saved contacts, and text muting depends on the messaging app - needs real-device testing.
3. Clock rollback can extend a temporary unlock / passcode lockout (wall-clock based).
4. First-app-after-unlock attribution depends on event ordering.
5. App Check is not enabled: Play Integrity attestation would reject sideloaded APKs, so turning enforcement on only makes sense for a Play-distributed build.
6. Crashlytics collection is on by default (disclosed in the privacy policy and Data safety draft); a parent-facing opt-out is not built.
7. The opt-in notification digest is stored in plain app preferences on the device.