PROP-45 - Seperate History and Last Hearbeat Endpoints

[JeffMboya]

What type of PR is this?

This is a feature because it separates the proplet heartbeat history into its own dedicated endpoint, resolving issue #45.

What does this do?

Previously, GET /proplets/{id} returned the full alive_at array (every heartbeat timestamp) as part of the proplet object, which polluted every proplet response with unbounded history data.

This PR makes the following changes:

• Removes alive_at from the GET /proplets/{id} and GET /proplets responses. A new last_alive_at field (the most recent heartbeat timestamp) is added to the response so clients can still display last-seen time without fetching the full history.
• Adds a new paginated endpoint GET /proplets/{id}/alive-history?offset=N&limit=N that returns the full heartbeat history for a specific proplet.
• Adds GetAliveHistory to all storage backends (postgres, sqlite, badger, memory). The history is retrieved from the existing alive_history column and paginated in-memory using offset and limit.
• Wires GetPropletAliveHistory through the full manager stack: service interface, implementation, HTTP endpoint, transport route, logging/metrics/tracing middleware, service mock, and storage repository mock.
• Adds GetPropletAliveHistory to the SDK interface and implements it in pkg/sdk/proplet.go.

Which issue(s) does this PR fix/relate to?

• Resolves Feature: Seperate History and Last Hearbeat Endpoints #45

Have you included tests for your changes?

No new tests were added. The existing manager and sqlite storage tests pass without modification. The pkg/proplet package has no test file (pre-existing gap), so PropletView and the .View() converters are covered only by the build and integration flow.

Did you document any new/modified features?

The new endpoint follows the same conventions as the existing GET /proplets/{id}/metrics endpoint. The SDK method includes an inline usage example consistent with all other SDK methods.

Notes

The alive_history column in postgres and sqlite stores timestamps as a JSON blob on the proplet row. GetAliveHistory retrieves the full blob and slices it. This is consistent with the existing storage approach and avoids a schema migration. A separate alive_history table would allow server-side pagination but is left as future work.