Evaluate Recent Adverts wording and grouping improvements without losing our per-class history (upstream 2085) #219

Deferred evaluation

Assess the remaining UI value of upstream PR 2085, merged on 2026-10-03. Our equivalent feature is already substantially implemented; this is not a request to replace it wholesale.

Snapshot checked 2026-10-04: our master 8bafcdf2a6bb0014127bce4822c8ad0399bd2f12, upstream master 9e49db9725d6346959c41ec23c66d96b7e43cc4c.

What upstream does / potential benefit

Groups the existing bounded Recent Adverts sample using the backend's advert_kind: Flood, Mixed flood/direct (empty path), Direct (empty path), and Other/unknown. It avoids inferring a class when route evidence is missing, preserves advert details and explains the historical-evidence limitation.

Potential value: clearer wording and a better distinction between observed routing evidence and assumptions about how the originating node transmitted. This does not establish physical proximity or a direct radio link.

What we already have

Merged #97 introduced a shared NodeAdverts component for the node page and side panel, with:

• All / Flood / Zero-hop / Mixed tabs, plus Unknown when relevant;
• up to 20 adverts per class, so a small number of floods is not hidden by a recent run of another class;
• 24-hour and 7-day counts, route badges, ?adverts= deep links and a provisional-backfill note;
• a single opt-in node-detail response, with bounded caching and privacy gates.

Upstream groups the existing 20-item sample rather than supplying our per-class history and windowed counts. Replacing our component directly would lose useful behavior.

Open questions / overlap

• Is our label Zero-hop too strong for a classifier based on raw route type? Compare the backend contract first; changing the label alone cannot fix a semantic mismatch.
• Should unknown/provisional evidence be explained more explicitly, including the limits of completed historical backfill?
• Can the clearer descriptions be adopted while retaining our tabs, counts, privacy behavior and API compatibility?
• Coordinate with Evaluate advert route-evidence semantics against our existing route_mask implementation (upstream 2088) #218, the separate backend assessment of upstream feat(analytics): split adverts using recorded route evidence Kpa-clawbot/CoreScope#2088. This issue owns presentation and interaction, not storage or migrations.

Evaluation checklist

• Compare real response shapes: our route_class / recentAdvertsByRoute versus upstream advert_kind.
• Agree terminology with the backend contract before editing labels or explanations.
• Preserve per-class retrieval, distinct counts, truncation notices, deep links and hidden-identity behavior.
• Validate full page and side panel at desktop/mobile widths, keyboard navigation, empty/mixed/unknown states and older server responses.
• Record whether only wording/tooltips are useful, a larger adaptation is justified, or no change is needed.

No implementation or deployment decision has been made.