Hackathon 25.2: extend Browserless testing section with Signals, Geolocation, AI testing

Describe your motivation

The flow/testing/browserless section on docs.vaadin.com already covers the mechanics well (Getting Started, Component Testers, Querying Components, Spring Security, Snapshots, Non-Spring Projects, Quarkus, Optimizing Tests, Migrating from UI Unit Testing). The comparison with end-to-end testing is also there, briefly.

What is missing in 25.2 is per-feature guidance for the new platform APIs:

1. Signals testing patterns. The current docs do not show how to assert against a Signal-driven UI in a browserless test. Patterns like "set a ValueSignal, then assert the component bound through Signal.computed / Signal.effect updates synchronously" are exactly the kind of thing the harness is good at, but there is no page on it.

2. GeolocationSimulator and the Geolocation testing story. com.vaadin.flow.component.geolocation.GeolocationSimulator exists and works inside browserless tests via GeolocationSimulator.current().grantPermission() plus setLocation(...). None of this is documented today; users have to read the source of vaadin-map-flow and the simulator class to discover it.

3. AI Components testing. AIOrchestrator and friends require a ChatClient.Builder and an LLMProvider. Without a documented test double for these (or a recipe for mocking Spring AI), it is currently impossible to ship browserless tests for views that depend on the AI components.

4. The decision tree per feature. The existing comparison section explains the broad strokes ("browserless is fast, TestBench is the real browser") but does not enumerate, for each 25.2 feature, which tool to pick. Clipboard needs TestBench because there is no simulator. CollaborationEngine real-time sync needs TestBench because the WebSocket dispatch is browser-only. Geolocation should default to browserless because the simulator exists. MasterDetailLayout, Sliders, MessageList attachments all run fine in browserless. A short table would close this gap.

Describe the solution you'd like

Three concrete additions, in order of value:

1. A new sub-page "Testing Signals" under /docs/latest/flow/testing/browserless/ covering: ValueSignal / ListSignal / Signal.computed / Signal.effect / the bind* family, with one or two minimal-repro tests that show the synchronous propagation.

2. A new sub-page "Testing Geolocation" documenting GeolocationSimulator.current(), grantPermission(), setLocation(lat, lon, accuracy), and requests(), plus the BrowserlessExtension boilerplate needed to use them.

3. An expansion of the existing comparison section with a per-feature table: each row a 25.2 API or feature, columns "browserless", "TestBench", "blocked / needs test double". Roughly 12 to 15 rows.

A standalone "Testing AI Components" page would be valuable too.

Start with the existing flow/testing/browserless documentation and its browserless-versus-TestBench comparison. Verify the Signals, GeolocationSimulator, and AIOrchestrator testing details against the referenced APIs and source, then add the requested Signals and Geolocation pages, AI guidance, and per-feature decision table; done means all three additions cover the listed 25.2 cases.