Add last_successful_submission timestamp to /api/v1/status

Tracked in Linear as QUI-830.

Problem

A node that mines valid solutions but lands zero extrinsics still reports is_mining=true, and its container stays Up. There is no signal that submissions are failing, so a total-submission-failure class is invisible to operators and monitoring until someone notices proofs_won has stopped moving.

This has now been independently corroborated by two separate field reports (#22, #26), in both cases as the part of the failure with the worst operator impact: the node looks healthy while silently missing every round.

Change

Add a last_successful_submission timestamp to /api/v1/status, set on each accepted submit_proof. A stale or null value while is_mining=true then directly indicates the submit path is broken.

Why this is independent of the submit-path fixes

The connection-swap and poisoned-pool defects (#26) are about why submits drop. This ticket adds the visibility that would have surfaced those failures on its own. The field is worth shipping regardless of how the submit path is fixed, and it guards against future regressions in that path.

Acceptance

• /api/v1/status includes last_successful_submission (ISO timestamp, null before the first accepted submission).
• The field updates only on an accepted submission, not on a mined-but-unsubmitted solution.