v1.17.0

## v1.17.0

A browser tab can clear a site’s challenge, follow its redirect, and render a PDF. Then a second request for that same PDF can still get blocked.

That was the remaining hole in inline-PDF retrieval.

Thanks to [Anand Patel](https://github.com/acpatelmd) for reporting [#9334](https://github.com/jo-inc/camofox-browser/issues/9334), reproducing this with PubMed Central’s challenge flow, and contributing [#10784](https://github.com/jo-inc/camofox-browser/pull/10784).

### Inline PDFs now use what the browser actually received

`POST /tabs/:tabId/fetch-current-resource` now first uses the matching main-frame PDF response already received by the managed browser tab.

This matters for sites where the tab can render the PDF after a JavaScript or bot-check redirect, but a separate Node-side request gets HTML or a 403.

The route still stays scoped to the current managed tab and its existing download-artifact flow. It does not add arbitrary authenticated fetches.

Known oversized PDFs are rejected from their `Content-Length` before their body is read. The existing 50 MiB limit remains in place.

### More reliable recovery

- A create-tab request now has enough time to rebuild one unhealthy browser session and create its replacement page.
- The E2E client retries the documented recoverable session-restart response instead of treating a browser RSS-safety restart as permanent failure.

### OpenClaw and Windows maintenance

- Updated the OpenClaw plugin to the current Plugin SDK contract.
- The package now uses the declared Camoufox downloader directly.
- Added reproducible macOS/UTM tooling for investigating hosted Windows E2E failures locally. Generated VM media and disks are not part of the repo.