feat(push): report push capability so clients stop offering a feature that cannot work

[RonenMars]

Closes #519.

The server decides at boot whether Live Activity push can work and logs it (live_activity.enabled / live_activity.disabled), but that decision never reached a client. So mobile offered a feature that silently no-ops for every user who is not the maintainer — the APNs .p8 is a server-side maintainer-owned signing secret bound to the app's bundle id.

A feature that is absent is fine. A feature that is present, enabled in the UI, and silently does nothing is not.

What changed

GET /api/info and GET /api/push/health both carry an additive push object:

push: {
  liveActivity: boolean          // can this server send an ActivityKit push right now
  notifications: boolean         // ordinary push. always false today
  liveActivityReason?: string    // present only when liveActivity is false
}

liveActivity comes from the server's own wiring state (liveActivityNotifier !== null) rather than a re-read of the environment, because credentials alone do not enable it — the sender is only built when the push token store opened too.

notifications is a hardcoded false, reported rather than omitted precisely so a client cannot infer ordinary push works because Live Activity push is configured: expo-server-sdk is not a dependency and PushRepository.listDeliverable() has no caller.

liveActivityReason names the missing environment variable, never its value — one test locks that down. The half-configured case (APNS_KEY set, team/bundle missing) is the hardest to diagnose, so it names them explicitly.

available was deliberately NOT changed

available on /api/push/health reports whether the SQLite token store opened, not whether credentials exist — which reads like the bug. It was left alone because the released app renders it verbatim:

tb-mobile/app/notification-health.tsx maps it to "Push store is available / unavailable (registration cannot persist)".

Retargeting it at credentials would make every non-maintainer server tell its user that registrations cannot persist — false, since the repository is open and register() works — and would point debugging at the database instead of the missing .p8. parsePushHealthResponse only type-checks it as a boolean, so the wrong sentence would render with no parse error. That trades one lie for another.

The new push object sits alongside it. On /api/push/health the pairing of "available": true with "liveActivity": false is the honest statement of the situation.

Backward compatibility

Purely additive. parsePushHealthResponse builds its result explicitly and ignores unknown keys, so released clients are byte-for-byte unaffected. A client that does not know push must read its absence as unknown, not unavailable.

Needs a paired tb-mobile issue: mobile should hide or disable the Live Activity affordance when push.liveActivity is false rather than registering tokens nothing will ever send to.

Verification

npm run lint exits 0. 67 push tests and 171 server/capabilities/http-log tests pass.

Positive control: forcing the wiring to a constant in each direction turned exactly the opposite two HTTP tests red (liveActivityPushEnabled: () => true → both "without credentials" cases; () => false → both "with credentials" cases). The tests read the server's real state, not a constant.

Note

docs/compatibility/tb-mobile.md did not list the push endpoints at all, despite mobile having shipped consumers for both. Closed in this PR.