Track Action Resume integration with a future unified composer activity surface

[lastobelus]

Context

Upstream PR pingdotgg/t3code#8693 briefly introduced a unified composer activity/banner surface. It shipped in nightly 1225 and was reverted by pingdotgg/t3code#8733 in nightly 1226, so LastCode should not restore or depend on that reverted implementation now.

The useful architectural idea may return in a different form. If upstream reintroduces an equivalent unified activity surface, LastCode's Action Resume states should integrate with it instead of growing a parallel status UI.

Reference screenshot from the original upstream implementation: composer activity/banner screenshot.

Desired mapping if the upstream surface returns

• A running Project Action appears as a waiting-action composer activity with the action name, elapsed time, priority, and controls for Cancel and Open Terminal.
• An interrupted or process_lost Action becomes an actionable warning with Resume and Discard.
• Success, failure, and cancellation become durable timeline/log entries plus the normal automated follow-up. They should not remain as sticky composer status.
• Mobile remains an independent client implementation and should continue using its existing Waiting/interruption cards unless the shared product model changes.

Trigger

Do this only when upstream reintroduces a unified composer activity architecture, or an equivalent shared model that can represent provider and Project Action activity without LastCode-only parallel machinery.

Non-goals

• Do not restore the reverted fix(web): unify activity logs and composer banners pingdotgg/t3code#8693 code now.
• Do not introduce a compatibility layer for an upstream surface that does not currently exist.
• Do not redesign mobile solely to mirror the web composer's presentation.
• Do not add race-handling machinery beyond cases that occur in normal solo-developer use.

Acceptance criteria

• Action Resume uses the shared activity model rather than a second composer-status system.
• Running, interrupted, lost, completed, failed, and cancelled Action states have the mappings above.
• Terminal controls remain available while an Action is running.
• Terminal states remain visible in durable history after the composer activity clears.
• Web/desktop and mobile behavior are each tested according to their native presentation.