Feature/android parity 196 199

[CHEF-SAVY]

Android feature parity: acceptance token, reminder timing, notification action, widget refresh

Four Android parity gaps from PARITY.md, one commit each. PARITY.md rows are updated
alongside each change.

1. Beneficiary acceptance token (#196)

Acceptance-link parsing lived inline in MainActivity and only the vault ID was treated as
a first-class value. Moved it into VaultDeepLinkParser.parseBeneficiaryAccept(), which now
returns a BeneficiaryAcceptLink(vaultId, token) — the token is validated against the same
allowlist as vault IDs and forwarded through AcceptanceViewModel into the
POST /vaults/{id}/accept request body. MainActivity.extractBeneficiaryAccept delegates to
the parser, so BeneficiaryAcceptanceTest keeps covering the same behaviour.

Added BeneficiaryAcceptTokenForwardingTest, a regression test that walks the token from the
incoming Uri all the way to the API call and to the serialized request body.

2. Check-in reminder lead-time scaling (#197)

Ported the formula from iOS NotificationService.scheduleCheckInReminder:

• primary reminder at min(checkInInterval / 10, 24h) before expiry, floored at 60s
• a second "Check-in Urgent" reminder 2h before expiry for short check-in intervals, but only
  when it would actually land after the primary one

NotificationHelper.scheduleCheckInReminder() enqueues both as unique WorkManager work keyed
by vault ID with REPLACE, so any TTL change (a check-in, a socket update) simply re-times the
pending reminders; a non-active vault cancels them. Delivery is a small CheckInReminderWorker.
VaultViewModel re-schedules on vault load and on every in-place vault update.

NotificationHelperTest covers short, medium and long TTL windows, the 24h lead-time cap, the
60s floor, and when the secondary reminder is/isn't scheduled.

3. Actionable "Check In" notification (#198)

Reminder notifications on the ttl_reminders channel now carry an inline Check In action.
The action reuses the existing ethosprotocol://vault/{id}/check-in deep link, so it opens
VaultDeepLinkScreen's check-in branch — the same biometric-gated path as the in-app button —
rather than firing the API from a receiver, which would let anyone holding the device extend a
vault from the lock screen. This matches iOS's .authenticationRequired on CHECK_IN_ACTION.

The action's PendingIntent uses a request code offset clear of both the content intent and
every vault notification ID, so the two intents can't be collapsed by FLAG_UPDATE_CURRENT.
CheckInNotificationActionTest covers the action wiring, its deep-link target, the request-code
separation, and that a vault-less notification carries no action.

4. TTL-aware widget refresh policy (#199)

Ported the urgency tiers from iOS TTLWidget.computeNextUpdateInterval into
VaultWidgetUpdateWorker.determineUpdateInterval: 15m at ≥6h, 10m at 1–6h, 5m at 30m–1h, 2m
under 30m. The existing 60m tier is kept for vaults more than a day from expiry (Android-only —
that vault moves too slowly to be worth frequent wake-ups).

Because WorkManager floors periodic work at 15 minutes, the worker now schedules itself as
unique one-time work with an initial delay, re-queuing after every run — the direct analogue of
iOS's .after(nextUpdate) timeline policy. Rescheduling happens on every path, including API
errors and empty vault lists, so a single failure can't stop the widget updating for good.
VaultWidgetUpdateWorkerScheduleTest covers each tier boundary plus near-expiry and long-TTL
vaults.

Notes

Tests are added but not run — there's no reliable way to execute the Android test suite in this
environment right now.

Closes #196
Closes #197
Closes #198
Closes #199

[drips-wave]

@CHEF-SAVY Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits