docs: rebuild pass-data guides (route/query parameters & templates) on signals

[peholmst]

Rewrites the three pass-data guides to use Vaadin 25.2 signals for reading URL parameters reactively. The guides stay consistent: route parameters use a manual ValueSignal pattern (the router state signal doesn't fit HasUrlParameter), while route templates and query parameters both read reactively from UI.routerStateSignal().

Route Parameters (HasUrlParameter)

• Hold the route parameter in a ValueSignal as the single source of truth: setParameter() writes the value, components bind to it, and a Signal.effect navigates the view to itself to keep the URL in sync.
• Reordered so parameter mechanics (accessing, optional, wildcard) come first and the signal pattern ties it together at the end.

Route Templates (router state signal)

• Read template parameters reactively from UI.getCurrentOrThrow().routerStateSignal(): derive a Signal per parameter and bind components to it, so the UI updates automatically on navigation.
• Documents the defensive-read requirement — a binding is first evaluated during view construction, before the router has populated the state, so default (orElse) rather than throw (orElseThrow).
• Keeps BeforeEnterObserver as the imperative alternative; converts the optional/wildcard sections to focused RouteParameters accessor snippets and removes stray literal snippet markers that were rendering to readers.

Query Parameters (router state signal)

• Read the parameter reactively from routerStateSignal().get().location().getQueryParameters(), derive a Signal per parameter, and two-way bind a field to it with bindValue(signal, setter) — the field reflects the URL, and edits navigate the view to itself with merged parameters.
• Keeps the QueryParameters immutability and merging() rules; keeps BeforeEnterObserver as the imperative alternative.

Master-Detail (follow-up)

• Aligns the "Representing Selection in the URL" note in add-master-detail.adoc with these guides: drops an over-promising "planned for a future release" note (reading parameters reactively already works via routerStateSignal(); writes go through navigate()) and links all three guides.

All example views compile in the docs project, and the runtime behavior of each pattern was validated (direct navigation, self-navigation, optional/missing params, regex-constrained 404s, two-way field binding — no navigation loops or server errors). The route-template and query-parameter idioms match hand-tested reference implementations.

🤖 Generated with Claude Code

[github-actions]

Preview Deployment

This PR has been deployed for preview.

URL: https://docs-preview-pr-5672.fly.dev

Built from 379b891

[Artur-]

I think the order on this page could be improved as it reads a bit like:

1. Accessing the Route Parameter Value
2. Optional Parameters
3. Wildcard Parameters
4. Naah, don't actually do as shown above, do it like this (Holding the Parameter in a Signal)

It could be restructured so you start from "This is how you get a parameter into the UI through a signal", then "optional parameters" -> "wildcard parameters"

I'm not sure you even need to explicitly spell out that you don't have to use a signal, or maybe spell it out like that in the first part.