fix(session-list): show every quick-action on an Android long-press

[chphch]

Android drops five of the eight long-press actions

Long-pressing a session on Android shows three entries. The rest are discarded with no error and no indication that anything is missing, so the menu just looks shorter than it is.

The path:

SessionsList.tsx:472, ActiveSessionsGroupCompact.tsx:268	onLongPress: showActionAlert
useSessionQuickActions.ts:298-305	builds one button per action, calls Modal.alert('Session', undefined, buttons)
ModalManager.ts:42	on native that is RN Alert.alert(title, message, buttons)

Android renders Alert.alert through the platform AlertDialog, which has exactly three button slots — positive, negative, neutral. Anything past the third is dropped.

The list currently holds seven actions plus Cancel:

details · resume · fork · duplicate · copy metadata · copy metadata & logs · archive · Cancel

Five of them never render.

The change

Route the native long-press to SessionActionsPopover, which already exists and already handles this case: its native branch is a bottom sheet built from the same shared actionItems array, with no button cap. The Android menu then matches what the web context menu has always shown.

• Web (onContextMenu) is untouched.
• iOS gains the same completeness, since it shared the Alert path — its AlertController does not have Android's hard cap, but it stacks poorly past a few buttons.
• No new component, no new dependency; the sheet is the one the web path uses.

Verification

pnpm typecheck clean; app suite 909/909.

Not captured on a device: the failure is a platform dialog limit, so a web capture would show the working path and prove nothing. Happy to attach an emulator recording if that would help review.

---

_{CI on this PR fails at the install step for the reason in #1663 (pnpm-lock.yaml out of sync with happy-cli/package.json since e7e0ff6), not because of this change.}

[chphch]

Rebased onto current main (3cf9ce70f), plus two import cleanups the rebase made necessary.

Both hunk sites survived c63c80ff3 verbatim, so the fix is unchanged. What did change is that upstream has since added useSettingMutable to the storage import at SessionsList.tsx:5 (for the archive toggle), which collided with this PR's own copy of that import and made the merged file fail tsc with TS2300. Dropped this PR's line; upstream's now serves both.

Also dropped useSessionActionAlert, which this PR leaves unused once the long-press routes through the popover instead of Alert.alert.

pnpm typecheck clean; app suite 919/919.

[chphch]

@bra1nDump — the same "control is there but the user cannot reach it" class as #1582 and #1598, which you merged, except here the loss is silent: five of the eight quick-actions simply are not drawn, with no error and nothing to suggest the menu is incomplete.

useSessionQuickActions.ts:350-356 builds one button per action plus Cancel and hands them to Modal.alert, which on native goes to RN Alert.alert. Android's dialog has three button slots, so everything past the third is dropped on the floor. Web is unaffected — it renders its own modal.

Proof

Android emulator (Pixel 5, API 30, arm64), same session row, same account, one long-press. Left: the OS alert with three items. Right: the shared actions sheet with every item, Archive among them — the one a phone user most needs and never had. Both frames ran the APK's embedded bundle (1.7.0+chphch.*), not an OTA, and the builds differ by exactly this PR's diff.

Updated for the flat home list

Capturing this turned up a gap worth flagging: the original patch covered SessionsList and ActiveSessionsGroupCompact, but the home screen now renders FlatSessionRow since flatSessionList defaults on — and that row still went to Modal.alert. It also mounted the actions sheet only in its web-only no-swipe branch, so rewiring the press alone would have left the menu unreachable on a phone. Both are fixed, so all three rows that carry the menu behave the same.

Rebased onto current main: mergeable, CI green, happy-app suite 1077/1077. The change routes native long-press to the existing SessionActionsPopover rather than adding anything new, so if you would rather cap the alert and keep it an alert, say so and I will rework it that way.