[Feature Request]: bounded waypoint history and device-only removal

[RCGV1]

Platform

Cross-Platform

Description

Implement the firmware/Base UI portion of the waypoint delivery and local-lifecycle contract in meshtastic/design#139.

Firmware currently keeps a single received waypoint in devicestate.rx_waypoint; every new WAYPOINT_APP packet replaces it. This is why a user can be left with a stale waypoint screen that cannot be removed without reflashing (#3324). The earlier waypoint-management tracker (#9736) also identified bounded waypoint storage and channel selection, but did not define an implementation contract.

Required behavior

• Replace the single display slot with a bounded, persistent local waypoint store. A record must retain the decoded waypoint plus the received packet provenance needed for UI/display and destination context.
• Use the canonical mesh channel-resolution logic to retain the received channel/destination metadata. Do not infer a waypoint destination from position-sharing settings.
• Prune expired records before applying a documented, target-appropriate eviction policy. Receiving malformed, oversized, expired, or high-rate waypoint traffic must not grow RAM or flash without bound.
• Provide a Base UI waypoint list/detail flow on supported screens. It must allow selecting a waypoint for the existing compass/distance presentation and show expiry state.
• Provide Remove from this device for every locally retained waypoint, including a locked or received one. It removes only the local record, is available without a phone, and emits no mesh packet.
• Keep Delete for everyone distinct and out of this local-cleanup action. If/when surfaced on-device, it must remain subject to existing ownership/lock rules and route to the waypoint's original destination.
• Preserve behavior on headless devices; no screen/UI is required there, but the store must remain bounded and correctly prune records.

Scope boundaries

• This does not change the Waypoint protobuf or add destination fields: routing remains in the enclosing MeshPacket.
• This does not implement client conversation-history cards; that belongs to Android, Apple, and web follow-up work under design#139.
• This does not replace the geofence work tracked in [2.8.0] - Waypoint Geofences #10811. Any waypoint-store design should leave room for that module's local state without duplicating it.
• Standalone UI/MUI is a separate repository and needs a separate follow-up after the firmware store contract is established.

Acceptance criteria

• On a supported device, receive multiple waypoints, reboot, and verify the retained set is available rather than only the last packet.
• Expired records are pruned; capacity pressure follows the documented eviction order; native tests cover both behaviors.
• Selecting Remove from this device removes the selected record immediately, including a locked received waypoint; serial logs/packet capture prove no outbound waypoint/update packet is emitted.
• Destination/channel metadata uses the canonical resolver and survives persistence where the UI needs it.
• Native tests cover decode failure, malformed/oversized payload handling, expiry, duplicate/update identity, capacity/eviction, and device-only removal.
• Hardware validation covers at least one constrained screen device; a draft PR explicitly records any targets not hardware-tested.

Evidence / prior art

• Current implementation: WaypointModule::handleReceived assigns every received packet to devicestate.rx_waypoint and shouldDraw() renders that one slot.
• User-facing cleanup failure: [Feature Request]: deleting waypoints without needing to reflash #3324.
• Cross-platform source of truth: [PARENT] [ALIGNMENT]: Waypoint delivery, history, and local lifecycle design#139.
• Related but separate geofence device behavior: [2.8.0] - Waypoint Geofences #10811.