[browser-use-demo] only_n_most_recent_images is ignored — screenshots accumulate unbounded

### Summary

In `browser-use-demo`, the "keep only N most recent screenshots" feature is dead code. `sampling_loop()` accepts `only_n_most_recent_images` and the helper `_maybe_filter_to_n_most_recent_images()` exists, but the helper is never called and the parameter is never read. As a result every screenshot accumulates in the message history for the whole browser session, so context size and token cost grow without bound.

### Where (on `main`, `f37f168`)

- `browser_use_demo/loop.py:78` — `sampling_loop(..., only_n_most_recent_images: int | None = None, ...)` is declared but never used in the function body.
- `browser_use_demo/loop.py:176` — `_maybe_filter_to_n_most_recent_images()` is defined but has zero call sites.
- `browser_use_demo/streamlit.py:500` — the UI explicitly requests it: `only_n_most_recent_images=3, # Keep only 3 most recent screenshots for context`. The documented intent never takes effect.

### Impact

Long browser sessions send the full history of screenshots on every step, inflating token usage and latency, and can push past context limits — exactly the behavior the parameter was meant to prevent.

### For contrast

`computer-use-demo/computer_use_demo/loop.py` wires the same helper correctly (it's called inside the sampling loop). The browser demo appears to have dropped that call.

### Note

There's a second, subtler problem: in this demo screenshots are nested inside `tool_result` blocks, but the helper only inspects top-level `image` blocks — so even once it's called it would need to descend into `tool_result` content to actually remove anything.

Related (computer-use-demo variants): #118, #266.