Dismiss edit sheet only from its drag handle

[AKolenda]

Summary

Swiping down anywhere in the time-entry edit form dismissed the sheet. Once the form was scrolled to the top, leftover drag and fling deltas propagated to ModalBottomSheet through nested scroll, which treated them as a dismiss gesture. Losing in-progress edits to an accidental swipe is easy, especially while scrolling back up.

The form now consumes leftover vertical scroll and fling (ConsumeVerticalOverscroll), so swipes inside it only scroll it. The drag handle at the top still drags and dismisses the sheet as before. Lists nested inside the form (e.g. the tag picker) are covered by the same connection. The tablet inline presentation has no swipe-to-dismiss and is unaffected.

Scope and acceptance criteria

• Swiping down in the edit form, including when it is scrolled to the top, does not move or dismiss the sheet.
• Dragging the handle at the top of the sheet still dismisses it.
• Scrolling the form itself is unchanged.

Non-goal: other sheets (template editor, calendar, statistics) keep their current behavior.

Validation

Commands and focused tests actually run:

gradlew testDebugUnitTest --tests '*SheetSwipeDismissTest' -> 2 tests, 0 failures
gradlew spotlessCheck testDebugUnitTest lintDebug assembleDebug assembleDebugAndroidTest -> BUILD SUCCESSFUL

Verification status by scope:

• Host/unit/lint: passed. SheetSwipeDismissTest shows a downward swipe at the top of a scrolling form reaches the parent sheet without the guard (control) and delivers zero scroll and fling with it.
• Screenshot/UI: not affected; no baselines changed.
• Device/E2E: not run on a device or emulator.
• Backend/server evidence: not applicable.

Evidence and remaining gaps

Not yet exercised by hand on a device.

Safety and working tree

• No tokens, work data, or machine-specific paths are included.
• Unrelated changes were preserved.
• Generated artifacts are intentional and reviewed.