refactor(push): hold a tapped notification natively until JS acts on it

[chrisnojima]

Stack 6/7 on #29650.

Why

• A tap can be lost before JS acts on it. Master hands JS a tap as a one-shot event or a read-once initial notification, with iOS re-emitting on become-active and Android polling for a React context. A tap that lands before JS listens or during a reload can be dropped, and a tap that is read is gone even if navigation never happens.
• A tap for another account goes through a separate pending-push store rather than the navigation intent, and non-tap pushes are handed to JS too.

What this changes

• Native tap slot on both platforms. A tap replaces any held tap and gets a new id. peekPushTap() returns {payload, id} without clearing it, and ackPushTap(id) clears the slot only if id is still the held one. onPushTapAvailable announces a new tap.
  • Android: notifications open a non-exported PushTapActivity, which fills the slot and starts MainActivity.
  • iOS: didReceive fills the slot. A non-tap push no longer reaches JS. A read-message push that zeroes the badge for the current account clears pending notifications natively.
• JS:
  • JS subscribes, then peeks. push-tap-resolve.tsx maps the payload to a keybase:// route and target uid.
  • The route is queued as a navigation intent, and the tap is acked when the intent is consumed, superseded or discarded.
  • A tap for another account switches accounts through account-link-switch.tsx.
  • On Android the tap's message is still unboxed with localUnboxMobilePushNotification, once per tap and only when the tap's account is current.
• Removed: the old bridge surface (getInitialNotification, onPushNotification, engineReset), constants/types/push.tsx and followUser.

Judgment calls

• A plain link is dropped while a switch for a tapped push is in progress. Only an untargeted link, only within the tap's lifetime; otherwise a new intent supersedes the tap and acks it.
• The chat.extension mapping is dropped. Nothing on master sends that type; unknown types resolve to no route and are acked at once.
• A tap on the conversation that is already open is acked without navigating. On a phone that means the conversation is on top; in the split layout, the chat tab is focused with nothing above it.
• A dropped tap never unboxes later. Its pending unbox is cleared when the tap leaves the queue without its account becoming current.
• The push-permission prompt wins over a cold tap in getInitialURL, as on master. The tap stays queued and navigates once the router is ready.

Tests

• push-tap-resolve.test.ts ports the Go resolver table.
• push-tap.test.ts covers:
  • subscribing before peeking
  • a tap that was held before JS started
  • repeated peeks
  • stale acks
  • acks on consume and on no route
  • one unbox per tap
• PushTapSlotTest covers the Kotlin slot.
• The navigation-intents, account-link-switch, intent-consumption (split and phone) and linking tests cover supersede, drop and open-conversation handling.

Mutation-checked.