MCPJVM-385: Progress checkpoint persistence and observability for long-running execution

[nimbly-dev]

Description

During long-running execution, operators need persisted and live progress that makes active work distinguishable from stalled work. This story improves checkpoint persistence and bounded observability during long-running orchestration.

Scope

In scope:

• persist suite progress often enough during long-running orchestration
• improve bounded progress visibility for resumed long-running runs
• make in_progress state more operationally meaningful during resumed passes
• support watcher/external-verification-heavy long plans with clearer visibility

Out of scope:

• full artifact query redesign
• watcher/provider business logic changes
• SQLite state-store adoption as a prerequisite

Acceptance Criteria

• Persisted progress advances often enough to distinguish active work from stalled execution
• Operators can observe bounded progress summaries during long-running execution
• Long-running watcher/external-verification plans do not appear completely opaque while still active
• Progress reporting remains bounded and deterministic

Implementation Notes

• Start with stable checkpoint boundaries such as after completed plans, after orchestration passes, and at safe long-wait transitions where feasible.
• Keep live/reporting output bounded rather than dumping full internal execution payloads.

Testing

• UT for progress summary shaping
• UT for checkpoint persistence rules at stable execution boundaries
• IT for persisted progress visibility during a long-running resumed watcher workflow
• IT for persisted progress visibility during a long-running external-verification workflow
• fixture updates as needed to seed multi-plan long-running enterprise-like regressions