feat(deps): restore browser-harness in compare extra as a PyPI dep

[wintonzheng]

What

Restore browser-harness in the compare extra as a normal PyPI requirement (browser-harness>=0.1.5 ; python_version >= '3.11'), replacing the git-URL form removed in #25.

Why

The git-URL dependency was removed in #25 because PyPI rejects direct URL dependencies. browser-harness is published on PyPI (https://pypi.org/project/browser-harness/), so the extra can depend on it normally. It requires Python 3.11+ while rustwright supports 3.8+, so the environment marker keeps pip install rustwright[compare] working on older Pythons (the dep is simply skipped there). No version bump; this rides the next release tag.

Testing

• twine check PASSED on a locally built maturin sdist
• Rendered metadata: Requires-Dist: browser-harness>=0.1.5 ; python_full_version >= '3.11' and extra == 'compare' (no URL deps)

Checklist

• I kept this change focused.
• I added or updated tests for behavior changes. (n/a: metadata-only)
• I did not include private credentials, tokens, or internal-only artifacts.

[claude]

Summary

Narrow, well-motivated metadata change that correctly unblocks pip install rustwright[compare] by replacing an install-from-git comment with a real PyPI dep. One supply-chain confirmation is needed before merging.

🔴 Critical Issues (1)

• Supply-chain identity check required (pyproject.toml line 34): The old comment pointed to github.com/browser-use/browser-harness. The new dep pulls browser-harness from PyPI with no confirmation that the PyPI package is published by the same browser-use org. Package-name squatting is a real vector, and this PR does not include a link to the PyPI release page showing the maintainer matches (the body links to the project URL but the maintainer field / PyPI publisher is what matters). Before merging, confirm on https://pypi.org/project/browser-harness/ that the "Maintainers" or Trusted Publisher config belongs to the browser-use org that owns the original GitHub repo.

🟡 Suggestions (1)

• No upper-bound on the dep: >=0.1.5 is fully open-ended. browser-harness is still at 0.x so a <1 cap (>=0.1.5,<1) would be conventional for pre-stable software and prevent a hypothetical incompatible 1.0 from silently entering the compare environment. Low risk today since this is a dev/benchmark extra, but worth doing while the dep is new.

📝 Minor / Style (1)

• Marker normalization note: The source uses python_version >= '3.11' but the PR description notes the rendered wheel metadata shows python_full_version >= '3.11'. This is maturin/pip normalizing the marker and is functionally equivalent — PEP 508 version ordering applies to both. Just flagging so future maintainers aren't surprised by the discrepancy between pyproject.toml and METADATA.