C2a: Swipe-up to key symbol popup (MVP)

[AsafMah]

Part of #17. MVP - start here.

Swipe-up from a letter key emits that key's popup/moreKey symbol (symbols/numbers without a layer switch or long-press delay). Reuses the existing vertical-swipe gate (tryStartShortcutRowSwipe, PointerTracker.java ~1366) which already coexists with glide typing: fires on >=10dp vertical travel with abs(dY)>abs(dX) and sets mIsDetectingGesture=false, so it does NOT break swipe typing. Free on non-top rows; on the top row choose symbol vs shortcut. Also addresses "123 is far left".

Acceptance: swipe-up on a key inserts its popup symbol; glide typing unaffected.

[AsafMah]

Re-opening the design. Conclusion from the attempts (PR #69, now closed): a fluid swipe-up-to-symbol fundamentally collides with glide on the middle/bottom rows because up is a glide direction there. Gliding an upward word like buy (b->u->y) is net-upward and indistinguishable from a deliberate up-flick by shape; the only reliable discriminator (a pause/hold) destroys the fluidity that's the point. The only fluid, unambiguous up-motion is off the top edge (already used by the shortcut-row swipe). Future directions to consider: (a) restrict symbol-swipe to the top row only; (b) a non-overlapping trigger (e.g. a dedicated key/region, or shorter long-press delay); (c) only when glide is disabled. Keeping this open for a fresh design pass.

[AsafMah]

Another future direction (d, glide-free by construction): swipe off the side edges — swipe left from the leftmost-column key / right from the rightmost-column key. Same logic as the top edge: a glide stays inside the keyboard, so an off-edge horizontal swipe from the border keys can't be confused with a glide. Together the glide-free "frame" is: up-from-top-row, down-from-bottom-row (shortcut row already uses these), and left/right off the side columns. Edge/border keys could get fluid symbol access this way; interior keys still have no free direction.