Add REST API endpoints for OpenClaw and external integrations

[nevan69]

Summary

This PR adds a small machine-readable REST API to PiFinder so external tools such as OpenClaw can access PiFinder state, camera/solve data, screen images, and optionally send key events for remote UI automation.

The motivation is to make PiFinder easier to integrate with observing assistants, local automation systems, voice-control tools, and external display/annotation tools, while reusing PiFinder's existing shared state and starfield rendering logic.

Why

OpenClaw and similar tools need a stable way to query PiFinder without scraping the web UI or screen image. This PR exposes selected PiFinder state through JSON endpoints, including:

• current solve status
• location/time
• current solution
• visible stars in the current field
• IMU and SQM data
• screen image
• optional remote key input

This makes it possible for external tools to build higher-level workflows such as voice-assisted observing, large-screen starfield visualization, object explanation, or remote control.

Added endpoints

Read-only JSON endpoints

• GET /api/status
• GET /api/time
• GET /api/location
• GET /api/solution
• GET /api/visible_stars
• GET /api/imu
• GET /api/sqm

Image endpoints

• GET /api/screen
• GET /api/camera/raw
• GET /api/camera/debug

Optional control endpoint

• POST /api/key

/api/key allows an external tool to send PiFinder button events. This is useful for remote UI automation, voice-control integrations, or accessibility workflows.

Example:

curl -X POST http://pifinder.local/api/key \
  -H "Content-Type: application/json" \
  -d '{"button": "UP"}'

## Visible stars endpoint

`/api/visible_stars` uses PiFinder's existing `Starfield.plot_starfield()` logic and returns machine-readable star data including:

- HIP id
- magnitude
- RA / Dec
- projected x/y
- screen x/y
- label suggestion

It supports two coordinate sources:

- `source=camera`: uses `solution.camera_solve`, useful for the last camera plate-solved field.
- `source=screen`: uses top-level `solution.RA` / `solution.Dec` / `solution.Roll`, useful when trying to match the current UI/screen state, especially when `solve_source=IMU`.

## Examples

```bash
curl http://pifinder.local/api/status
curl "http://pifinder.local/api/visible_stars?source=camera&render_mag_limit=5.5"
curl "http://pifinder.local/api/visible_stars?source=screen&render_mag_limit=5.5"
curl http://pifinder.local/api/screen --output screen.png

[brickbots]

Hi @nevan69 !!! Thank you for this, it's a nice pattern to include the API endpoints in this way. For the PiFinder repo the main branch is our primary development branch.

The release branch is where we manage our releases. It's the default so people see the latest released code if they pull the repo without any target... but it also ends up being the default for PR's, which can be annoying/confusing for contributors.

I've switch this MR to be against main and cleared up an easy merge conflict. However, we've switched from Bottle to Flask on the main branch. I think almost all your work will port pretty easily, but the module/class names will need to be adjusted 👍