fix(android): include the from point in input.swipe

[Ayaan Gazali (ayaangazali)]

Rationale

input.swipe(from, segments, steps) documents from as "The point to start swiping from", and
segments as "Points following the from point in the swipe gesture". Only segments ever reached
the driver, so the gesture actually started at segments[0] and the caller's from was discarded:

async swipe(from: types.Point, segments: types.Point[], steps: number) {
  await this._device._channel.inputSwipe({ segments, steps }, kNoTimeout);
}

inputSwipe in protocol/spec/android.yml:172 has no from field, and the driver builds its
Point[] from segments alone before calling UiDevice.swipe. drag(from, to, steps) four lines
below does forward its own from, and the driver's inputDrag parses it, which is what made this
one stand out.

Since from is just the first point of the path, prepending it to segments fixes the behaviour
without touching the protocol schema or the device driver, which is the smaller change of the two
options in the issue.

Test

None, and I want to be upfront about why rather than have it look like an omission. tests/android/
needs a real device, and I do not have one, so I can verify the plumbing and the types but not the
resulting gesture on hardware. There is also no existing swipe coverage in that suite to extend.
flint is clean.

If you would rather this were confirmed on a device before landing, or would rather take the other
option from the issue and correct the documentation instead, both are completely reasonable and I am
happy either way.

Fixes #42348

---

thanks for assigning it. the one assumption I am leaning on is that UiDevice.swipe treats the
first element of the array as the origin of the gesture, which is what the parameter docs imply but
which I could not confirm by running it. freshman in college, so please do sanity check that bit :)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Anton Petnitsky (Mukller)]

Heads-up: this duplicates #42349, which makes the identical change (segments: [from, ...segments]) and additionally ships a regression test (\ ests/android/input.spec.ts). That PR is already approved and currently has active follow-up on CI flakiness of the new test.

Suggest consolidating on #42349 to avoid conflicting merges — the explanatory comment added here would still be a nice addition over there.

[Ayaan Gazali (ayaangazali)]

You are right, thanks for catching it. #42349 predates this by most of a day, makes the same change, adds the regression test this one lacks, and is already approved. That one should land.

Closing this. My mistake for not checking open PRs before opening it.