fix(goto): don’t forward sec-fetch-* headers

[Kikobeats]

Note

Low Risk
Targeted navigation header fix with tests; workspace dependency pins are tooling-only with no runtime behavior change beyond goto header filtering.

Overview
@browserless/goto no longer passes sec-fetch-* headers through setExtraHTTPHeaders. User-supplied headers are kept as rawHeaders for device/user-agent logic, then any key starting with sec-fetch- is dropped before extra HTTP headers are applied so Chrome can set correct per-request metadata (e.g. cross-origin fetch is not stuck with navigation-style same-origin values).

Monorepo packages switch internal @browserless/* and browserless dependencies from pinned ^13.x versions to workspace:*. New unit tests in packages/goto/test/unit/headers cover filtering and cross-origin subrequests.

^{Reviewed by Cursor Bugbot for commit 64fba54. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coveralls]

coverage: 91.866%. first build — next into master