Decide between vaadin.db.fetch.rows and vaadin.data.fetch.rows

feat/data-query-metrics adds vaadin.data.fetch.rows and vaadin.data.fetch.requested, measured at the data provider layer. vaadin.db.fetch.rows measures at the JDBC layer, requires DataSource proxying, and is opt-in behind vaadin.observability.database.

The two now overlap substantially and the names are almost identical. The data provider meter covers the common "which view reads too much" case, works for non-JDBC data providers, and needs no proxying.

Decide before both ship in 5.0

• Keep both, with documentation making clear when each applies.
• Or demote vaadin.observability.database further.
• Or drop the JDBC row counting and keep vaadin.db.query for per query spans only.

Shipping two near-identically named row count summaries with different capture points is the outcome to avoid.

Compare the data-provider metrics from feat/data-query-metrics with the JDBC-layer metrics behind vaadin.observability.database, including vaadin.data.fetch.rows, vaadin.data.fetch.requested, and vaadin.db.fetch.rows. Decide whether to keep both, further demote database observability, or retain only vaadin.db.query spans; done means the two near-identically named row-count summaries no longer overlap ambiguously before 5.0.