Expose last PushTo target (PUSH catalog / recent list) via API

[apos]

Summary

When an external client (KStars, SkySafari, etc.) sends a Goto command over the LX200 protocol, pos_server.py's handle_goto_command() creates a CompositeObject with catalog_code: "PUSH" and a monotonically increasing sequence number (e.g. shown on-device as "PUSH 1"), including its RA/Dec (J2000). This gets appended to shared_state.ui_state().add_recent(obj) - an in-memory RecentCompositeObjectList (state.py) that already tracks this history.

However, this list is currently not exposed through any API endpoint - there's no way for an external consumer (the web UI, a mount-bridge integration, a companion app) to query "what was the last PushTo target?" or the recent history in general.

Use case

Real-world example that surfaced this gap: during a live observing session with a friction-clutch mount (no encoders/absolute position feedback), a manual PushTo was sent to a target. Shortly after, external factors disturbed the mount's actual pointing (bumped the tripod, the clutch slipped under the OTA's weight, mount overbalance) - all common, everyday occurrences with this kind of mount, not edge cases. There was no way to ask PiFinder "what did I last push to?" to recover / re-issue a Goto to that target, other than manually re-finding and re-selecting it.

A simple GET /api/last_pushto (or a GET /api/recent returning the whole list) would let external tooling implement a "Goto last known PushTo target" recovery action, independent of whatever state a mount-bridge/INDI-side integration's own target-tracking might be in.

Proposed API

• GET /api/last_pushto - returns the most recent PUSH-catalog entry from ui_state().recent() (RA/Dec J2000, sequence number, timestamp if available), or 404/empty if none exists yet this session.
• Optionally GET /api/recent - the full recent-objects list (not just PUSH entries), for broader UI use.

Scope note: RecentCompositeObjectList is in-memory only and does not survive a PiFinder process restart - that's fine for the recovery use case above (same-session), so the initial implementation doesn't need to add persistence.

Context

Found while debugging a Mount Bridge (PiFinder_Stellarmate project) live session - the bridge's own target-forwarding state machine can lose track of "was this push-to already forwarded" across a driver restart, and having PiFinder's own authoritative PushTo history queryable would let bridge-side (or any external) tooling recover independently of that internal state.

[apos]

Correction based on further discussion: a single "last pushto" endpoint is not enough. PushTo targets are sequentially numbered (the on-device "PUSH N" label) and already form a browsable history - on the device itself, the existing Recent/object-list screen (ui/object_list.py) already lets the user page up/down through this exact list with the arrow keys and re-select (Goto/PushTo) any earlier entry by index, not just the most recent one.

Revised proposal: the API needs to expose the whole recent/PushTo list (not just the last item), with each entry addressable (e.g. by its sequence number) so external tooling can mirror the same "walk through history and re-select any past target" behavior the on-device UI already has - not just "recover the last one."

• GET /api/recent (or /api/pushto_history) - the full list from ui_state().recent() (or just the catalog_code == "PUSH" subset), each entry with sequence, ra/dec (J2000), description, and ideally a timestamp.
• Optionally a way to re-select/re-push a specific entry by sequence (e.g. POST /api/goto?sequence=N), so a client isn't limited to read-only inspection.

The single-endpoint idea in the issue description above is superseded by this.