Apply force=True to Connect/More clicks to bypass interop-outlet pointer interception

[ds-amrit]

Summary

Three .click() calls in linkedin/actions/connect.py are blocked by LinkedIn's interop-outlet overlay element, which intercepts pointer events on top of the More button and Connect menu items. Playwright's default click action refuses to proceed when an intercepting element is detected, so the connect flow fails with a 30s TargetClosedError after 54+ retry attempts.

This PR mirrors the existing force=True pattern already used on send_btn.first.click(force=True) in _click_without_note and applies it to the three earlier clicks that lacked it.

Reproduction

1. Run a self-host build (ghcr.io/eracle/openoutreach:latest as of 2026-05-24, pinned digest sha256:3f3d4f2b…).
2. Complete onboarding, let the daemon discover and qualify a few profiles.
3. As soon as a profile is promoted to READY_TO_CONNECT, the connect task fails with the traceback below and the same task gets re-queued indefinitely.

playwright._impl._errors.TimeoutError: Locator.click: Timeout 30000ms exceeded.
Call log:
  - waiting for locator("section[componentkey*=\"com.linkedin.sdui.profile.card\"]")
      .first.locator("button[aria-label=\"More\"]:visible, ...").first
    - locator resolved to <button aria-label="More" ...>
    - attempting click action
    - <div id="interop-outlet" class="theme--light" data-testid="interop-shadowdom"></div> intercepts pointer events
    - retrying click action (54 retries × 500ms)

The locator resolves correctly (the right button is found and is visible/enabled/stable). It's the overlay's pointer interception that aborts the click. First reproduced on macOS Apple Silicon under Colima + Rosetta, but the issue is specific to LinkedIn's current rendering, not the host platform — anyone running the latest LinkedIn UI will hit it.

Fix

Add force=True to:

• direct.first.click() in _connect_direct
• more.first.click() in _connect_via_more
• connect_option.first.click() in _connect_via_more

The fourth click in this flow (send_btn.first.click(force=True) in _click_without_note) already uses the same pattern — this PR makes the rest consistent.

Why force=True is safe here

Playwright's pre-click checks already verify the locator resolved to the correct, visible, enabled, and stable element (per the call log). The only check force=True skips is the "is anything intercepting?" actionability check. Since the intercepting element is a transparent overlay (interop-outlet) sitting above an explicitly resolved button, clicking through it lands on the intended target.

Test plan

• Verified on ghcr.io/eracle/openoutreach:latest against current LinkedIn UI (June 2026): without the patch, ~10 connect tasks fail in a row; with the patch, ~14 connection requests went out successfully across two sessions.
• No regression on the existing force=True site (_click_without_note).
• Diff is minimal — 3 lines, single file, identical to existing pattern.