feat(web): swipe session rows to archive or delete (stacked after #4839)

[btli]

Related issue

Supersedes closed PR #3985.

Stacked dependency: This PR depends on #4839 and must be merged only after #4839. It was developed against exact finalized #4839 head 17f71a3a31755c4f0e319d63640c29d5bf3a19b3 (17f71a3a3). GitHub cannot use a fork branch as this upstream PR's base, so this PR targets main; its displayed diff includes #4839 and will shrink to the swipe-only changes after #4839 merges.

Summary

• Adds configurable touch swipes on session rows: archive/unarchive in one direction and reveal a confirmation before delete in the other.
• Fixes Android long-press reliability by porting feat(web): project folder context menu on right-click and long-press #4060's accepted unified row recognizer: swipe, scroll, hold-menu, and continuing-touch drag now have one owner.
• Makes the actual row link non-draggable, keeps context menus controlled and non-modal, and suppresses native long-press pan/selection/context-menu claimants while the gesture is armed.

ELI5: Hold a session to open its menu; keep pulling the same finger to close the menu and drag the session. A sideways move still swipes, and an up/down move still scrolls.

touch down -> horizontal move: swipe
           -> vertical move: native scroll
           -> still hold: one menu -> same-pointer pull: dismiss + drag

Test Plan

• NODE_OPTIONS="--localstorage-file=<temp>" bun run test -- src/shell/Sidebar.rowActions.test.tsx passes (65 tests).
• uv run pytest tests/e2e_ui/sessions/test_sidebar_session_gestures.py -q passes (6 Chromium CDP touch tests): stationary hold opens exactly one menu; the same pointer continues into drag; horizontal swipe and vertical scroll arbitrate correctly around the hold boundary; pointer cancellation and real capture loss reset cleanly; unexpected native dragstart and pointercancel fail the relevant paths.
• RED/GREEN mutation — link ownership: removing draggable={false} makes the unchanged stationary-hold browser test fail because the live anchor reports draggable === true; restoring it passes.
• RED/GREEN mutation — persisted-action race: changing Settings after swipe lock but before release fails when release reads the live mapping; snapshotting the mapping at pointer-down keeps the in-flight action stable.
• RED/GREEN mutation — unified ownership: replacing RowGestureTouchSensor with dnd-kit's old 250ms TouchSensor makes the pre-hold ownership and post-hold menu/drag tests fail; restoring unified ownership passes 6/6.
• bun run lint, bun run format:check, bun run type-check, bun run build, and uv run --no-sync pre-commit run --all-files pass.
• Android: focused OmnigentWebViewClientTest plus assembleDebug pass. The full 73-test Android unit run retains one unrelated existing MainActivityTest system-bar polarity failure.
• Genuine Android emulator Show-taps verification was unavailable at final head: adb devices -l returned no connected devices.

Demo

Pending: a final-head Android mobile-app recording with Developer Options Show taps enabled must be uploaded as an embedded GitHub attachment. Older external demo links were removed because they predated the unified long-press/menu-to-drag fix and did not prove this head.

Type of change

• Bug fix
• Feature
• UI / frontend change
• Refactor / chore
• Docs
• Test / CI
• Breaking change

Test coverage

• Unit tests added / updated
• Integration tests added / updated
• E2E tests added / updated
• Manual verification completed
• Existing tests cover this change
• Not applicable

Coverage notes

Focused React tests cover the retained swipe actions and reset seams. Chromium CDP tests exercise genuine touch ordering across stationary hold, controlled menu open/dismiss, same-pointer drag activation/drop, and native vertical scrolling. Final-head Android manual evidence is explicitly unavailable because no adb device was connected.

Changelog

Swipe session rows on touch devices to archive them or request deletion.

[github-actions]

@btli Thanks for the PR! It doesn't reference an issue yet.

We require an issue for every PR, so the work can be prioritized before it's reviewed. Add one to the description:

• Closes #123 if this PR finishes the issue. That links it, gives your PR the issue's priority, and closes the issue when this merges. You can also link it from the Development section of the sidebar.
• Part of #123 if this is one step towards it. Related to, Towards, and Refs work the same way, and leave the issue open.

No issue exists for this yet? Open one first, then reference it. That's how we track what's worth doing, and it's usually quicker than it sounds. Note a reference has to point at an issue: naming another PR doesn't count.

The only exceptions are changes with no user-visible behaviour: pure Refactor / chore, Docs, or Test / CI work. If that's genuinely what this is, check that box under Type of change. Anything that fixes a bug, adds a feature, or changes the UI needs an issue, even when it also touches docs or tests.

See CONTRIBUTING.md for the full policy.

No action is taken beyond this comment.