fix(click): emit every press in a DOM multi-click sequence

[NianJiuZst]

Summary

For a DOM ref or CSS selector, click_count: 2 currently sends only one press/release pair with CDP clickCount: 2. Chrome emits dblclick, but the first mousedown, mouseup, and click never occur. A widget that uses the first click to select an item and the second to open it therefore receives a different sequence from a normal double-click.

Emit every consecutive native press/release pair for DOM clicks. Fixes #349.

Reproduction and evidence

Failing base: 8cbcc490. Validated PR head: c8269cc1.

On a page with #target, record mousedown, mouseup, click, and dblclick, including each event's detail and isTrusted. The affected command is:

bsk click '#target' --click-count 2 --session <session-id>

The committed dom-multiclick.browser.test.ts invokes the equivalent production handleClick request, then compares it with an explicit count-1/count-2 native CDP control on the same element.

Base:
  mousedown(2), mouseup(2), click(2), dblclick(2)

This PR and the native CDP control:
  mousedown(1), mouseup(1), click(1),
  mousedown(2), mouseup(2), click(2), dblclick(2)

All recorded events have isTrusted: true. The hosted browser log includes DOUBLE_CLICK_PROOF with identical fixed and control arrays. The defect is the missing first click; it is not a missing dblclick event.

Implementation

In dispatchClickAtPoint, iterate counts 1 through the requested count for both DOM and visual-point paths. Previously only the visual-point path emitted the full sequence.

• Keep one initial mouse move and send one press/release pair for each count, preserving coordinates, button and modifiers.
• Retain abort and overlay checks before each press, plus the existing release cleanup.
• Preserve visual-point-specific target verification; this change does not add equivalent semantic target revalidation to DOM clicks.
• Require a positive safe integer before iterating a DOM click count.
• Replace the old unit expectation of three mouse commands for a double-click with the complete five-command sequence, and cover cancellation or a newly obstructing overlay after the first release.

Validation

Local environment: macOS, Node 26.10.0, pnpm 10.17.0, Vitest 4.1.6, Chrome 153.0.8010.54.

Suite / check	Result and coverage
interaction.test.ts	120 tests passed; corrected ref double-click sequence and 2 new between-press interruption cases
dom-multiclick.browser.test.ts	1 test passed; actual trusted DOM event sequence matches the native control
visual-ref.test.ts	13 tests passed
file-transfer.test.ts	28 tests passed for other callers of the shared click path
TypeScript compile, changed-file Biome, git diff --check	Passed

Local focused total: 162 passed. The new browser regression failed against the base implementation with only the count-2 events.

Use the repository's declared pnpm 10.17.0, from the repository root. The local runs used npm exec --yes --package pnpm@10.17.0 -- pnpm ... to select that version. Set BSK_CLICK_CHROME to an installed Chrome executable; without it the browser test is skipped.

pnpm install --frozen-lockfile
pnpm --filter @browser-skill/extension exec wxt prepare
BSK_CLICK_CHROME=/path/to/chrome \
  pnpm --filter @browser-skill/extension exec vitest run \
  src/tools/__tests__/interaction.test.ts \
  src/tools/__tests__/dom-multiclick.browser.test.ts \
  src/tools/__tests__/visual-ref.test.ts \
  src/tools/__tests__/file-transfer.test.ts
pnpm --filter @browser-skill/extension compile

Hosted status for c8269cc1, checked 2026-09-26 UTC: all 8 reported checks passed, including frontend validation and browser validation. The browser job's *click*.browser.test.ts selection includes the new test; that job passed 12 tests across 8 files, including the existing debugging and observation suites.

Verification boundary

The browser regression exercises a selector against real Chrome; the ref path and interruption cases use unit adapters. The headless harness adapts tab/window metadata and invokes the extension handler directly, so it is not an installed CLI/daemon/extension end-to-end run. Both tests and observed output focus on double-clicks; the implementation also emits the requested consecutive sequence for larger valid DOM counts.