refactor(push): resolve a tapped notification in Go and route it

[chrisnojima]

Stack 8/9, splitting #29637. Parent: #29655.

Why

Tapping a notification has to work when the app is cold — which is exactly when JS is not running. On master the push payload is parsed in JS to decide where to navigate, so the thing that decides the destination is the thing that may not exist yet. Moving resolution into the service means the route is known the moment the tap reaches Go, and JS just consumes it when it comes up.

Master bugs this fixes

• A tap can be lost because JS is not up to parse it. The payload switch lives in stores/push.tsx; nothing resolves the tap before JS is running.
• A cold-start tap does not reliably open the conversation.
• A tap is retired when it is read, not when it is acted on, so a tap consumed by a client that then fails to navigate is simply gone.
• Account switching on tap is handled ad hoc through a pendingPushNotification store field plus an HMR-guarded subscribe hook, rather than as a property of the pending intent.
• Non-tap pushes are still handed to JS, doing work for notifications the user never touched.
• Dead bridge surface: getInitialNotification, onPushNotification and engineReset still exist on the native module.

What this changes

libkb.ResolvePushTap turns a push payload into a keybase:// route with a target uid and an id. The service holds it and exposes peekPushTapRoute/ackPushTapRoute plus a pushTapRouteAvailable notification. Android taps go to a PushTapActivity that hands the payload straight to Go; iOS does the same from didReceiveRemoteNotification. JS drains the route on connect and on notification, routes it through the linking config (which #29650 made correct), and acks it once navigation actually consumes it. The account-switch behaviour moves to account-link-switch.tsx, driven by the intent's target uid, so it is a property of the intent rather than a side store. constants/types/push.tsx and the dead bridge surface are deleted, and config.startup.followUser goes with them — it only becomes dead now.

chat.extension pushes are not routed. Master's JS mapped them to their conversation, but nothing has sent that type since the old share extension was removed, so it isn't carried over. An unknown type resolves to no route.

Why this one cannot be split further

The moment KBPushNotifier.buildPendingIntent points at PushTapActivity, the old JS tap path is dead. Any partial landing ships a build where notification taps do nothing.

Two fixes beyond a straight port of #29637

Both are present on the source branch; both are mutation-checked here.

• Logging out could log you straight back in. dropOnFailure asked tapForOtherAccount(), but a tap for the account being logged out of is not "for another account" while that uid is still set — and the teardown clearing the uid then makes it one, so the pending tap logged the user back into the account they had just left. The drop path is now account-blind, matching what clearPendingPushNotification-on-logout used to do.
• A tap could arrive with no reader. The connect-time peek ran alongside subscribe() rather than after it, and pushTapRouteAvailable is filtered per connection, so a tap landing between the peek's reply and the subscribe being applied was seen by nobody. On Android the tap genuinely arrives on another thread while the client is still coming up.

Verification

go build, go vet, gofmt, golangci-lint --new-from-rev master 0 issues; every test binary in the repo compiles. Android builds — javap confirms deliverPushTap in the rebuilt AAR. iOS builds, with yarn sync:kb-modules run so the compiled copy of the native module matches the source. yarn lint:all clean, unit suite green.

Worth confirming on device: chat.1.local.unboxMobilePushNotification now has no caller. Go's handler covers the normal path but not the case where its own processing threw, so a tap after failed Go processing may land on a conversation whose message was never unboxed.