feat(gestures): add step-one tap and gesture combining

[AsafMah]

Summary

This adds a conservative first step toward two-thumb typing: LeanType can optionally allow overlapping tap + gesture input within the current word.

The new behavior is intentionally narrow. A gesture may bypass the rapid-typing suppression only when another pointer is still active and the previous code input was a letter. Once all fingers leave the keyboard, the next gesture starts a new word and keeps the existing fast-typing guard.

What changed

• Adds two Gesture Typing settings:
  • Combine simultaneous tapping and additional gestures
  • Draw taps and gestures
• Adds a small debug overlay for tap points and gesture paths.
• Adds a narrow BatchInputArbiter overload so existing gesture callers preserve current behavior by default.
• Documents the step-one behavior and scope in docs/two-thumb-step-one.md.

Scope

This PR deliberately does not add the larger downstream two-thumb model:

• no phantom spaces
• no grace timers
• no delayed commit after all fingers lift
• no re-recognition of prior taps
• no custom spacing behavior
• no synthetic point insertion

Those can be evaluated separately after this minimal mixed-input gate proves useful.

Verification

Tested with:

./gradlew.bat :app:testOfflineDebugUnitTest \
  --tests "*BatchInputArbiterTest*" \
  --tests "*SettingsContainerTest.tapGestureCombiningSettingsAreSearchable" \
  --no-daemon --console=plain

Result:

BUILD SUCCESSFUL

[LeanBitLab]

why are we making the keyboard more complicated

[AsafMah]

@LeanBitLab Currently typing with the keyboard with two thumbs simultaneously /almost/ works.

There are plenty of people who want it - there was an old keyboard called "nintype" which was closed source and abandoned, but it had good two thumbs typing and once you learn it it's very hard to go back.
AsafMah#102

I maintain a fork with it, but it's hard to keep up with all of the changes in here.
I much rather not to maintain the fork and just have this keyboard contain these features.

As for complications - every release in this keyboard adds a ton of stuff. You just recently added a whole parallel gesture engine. I don't see why my features are the point where it's too complicated.

Either way - it's your repo, it's your choice.
If you don't want it in I'll just keep it in my fork.

[LeanBitLab]

As for complications - every release in this keyboard adds a ton of stuff. You just recently added a whole parallel gesture engine.

I am now regretting that 😄

I,ll try to implement,not sure ill try

[LeanBitLab]

1. Alternate Typing Flow: Because combining is strictly tied to physical overlap on the screen (getActivePointerTrackerCount() >= 2), rapid alternating typing (where one thumb lifts just before the other lands) won't trigger it. This makes the combining feature feel somewhat restrictive in real-world rapid usage.
2. Feature Gaps & Expectations: Implementing a partial mixed-input model without grace timers or phantom spaces might confuse users expecting a complete two-thumb experience, likely leading to immediate feature requests/issues to port the remainder of the downstream changes.
3. Complexity vs. Scope: We want to keep the touch-routing pipeline as simple as possible. Introducing this middle-ground gate adds maintenance overhead to critical paths like PointerTracker without delivering the full seamless experience.