fix(github): keep a multi-table apply Running while tables are still queued

[aparajon]

Why

DeriveApplyState named a post-copy phase (catching up, checksumming, post-checksum) whenever one task reached it and no sibling was copying — including when the remaining siblings had not started at all. A sequential multi-table apply whose first table entered its checksum reported the whole apply as Checksumming on the CLI status list and the PR comment status line, overstating progress while most of its tables were still queued with their entire copy ahead of them.

What

Phase names now surface only once every table has started. One new rung in the projection ladder, between Running and the phase names:

  ... ──▶ running? ──no──▶ any post-copy phase task AND any pending task? ──yes──▶ Running
                                        │ no (every table started)
                                        ▼
                          catching_up? / checksumming? / post_checksum?   (unchanged)

task states	before	after
{checksumming, pending ×10}	Checksumming	Running
{completed, catching_up, pending}	CatchingUp	Running
{checksumming}	Checksumming	Checksumming
{completed, checksumming}	Checksumming	Checksumming
{running, checksumming, pending}	Running	Running
{pending, pending}	Pending	Pending

The rung is the named predicate postCopyPhaseWithQueuedWork. The data plane's overall-state projection (deriveOverallState), which remote-mode applies report over gRPC and the control plane persists, applies the same rung so both drive modes agree. Only the projected label changes: phase tasks already counted as running-family for activity and stuck detection, so no gate or safety semantics move.

---

This PR was generated by Claude Code (claude-fable-5).

[Copilot]

Pull request overview

This PR keeps multi-table apply status as Running while post-copy work coexists with queued tables.

Changes:

• Adds the queued-work projection rung to DeriveApplyState.
• Adds regression coverage for mixed table states.
• The equivalent remote/gRPC projection still requires the same update.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Summary
pkg/state/apply.go	Adds the local queued-work projection, but the remote progress path can still report overstated post-copy phases.
pkg/state/apply_test.go	Covers queued and mixed post-copy state combinations.

Suppressed comments (1)

pkg/state/apply.go:109

• The projection contract is also described in docs/spirit_progress.md:181-190, which still says the phase is surfaced once every active table is draining/verifying and does not mention queued tables. After this change that documentation gives the wrong rationale for the {checksumming, pending} case; please update the canonical progress documentation alongside the code comment.

// The post-copy phases (13–15) surface the least-advanced active phase, and
// only once every table has started: while any table is still copying rows —
// or still queued with its whole copy ahead of it — the apply is Running.
// Once every table has at least begun and the active ones are draining or
// verifying, the apply names that phase.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.