v1.0.16

Added

• /action accepts use_proxy — and now says so. The daemon has read the field on
  /action for its whole life without documenting it, which is exactly why nothing
  used it: an undocumented parameter is one no caller dares depend on. docs/api.md
  now documents it under /action, and tests/test_action_use_proxy.py pins the
  pass-through together with the documentation, so the two cannot drift apart the way
  the field itself did.

Documentation

• Two consequences of the field that were previously invisible, both of them silent:

  • Switching the route restarts Chrome. Cookies and in-page state are lost, so the
    field belongs once per session, not once per click.
  • use_proxy: true with WARP not running degrades to direct without an error. The
    route is chosen only when is_warp_proxy_ready(). goto returns {ok, url, title}
    with no blocked field, so an agent that asked for WARP and got a datacenter-ASN
    wall sees a successful-looking response. The docs now say to check
    warp_proxy_ready from GET /status first, rather than leaving the reader to
    discover it.

  This is a pre-existing property of the field, documented rather than changed: making a
  forced route fail loudly would change /fetch behaviour for callers that currently
  pass use_proxy: true on hosts without WARP, and that is a separate decision.

• use_proxy on /action means something different from use_proxy on /fetch. A
  fetch auto-retries a blocked page through WARP when the field is omitted; an action
  cannot, because it is already driving a live session. Omitting it there means "leave
  the session on its current route", and false actively forbids WARP. The tests pin
  that the default is None and not False — collapsing the two would make every plain
  click silently drag a proxied session back to direct.