fix(desktop): skip archived session queries

[Phoenix500526]

Summary

Prevent archived sessions from remaining automatic query targets by:

• excluding archived sessions from bootstrap selection
• pausing automatic Skills and Plan refreshes while archive or delete actions are pending

This reuses the existing pending row-action state, so renderer cleanup still happens only after the Runtime Host confirms the operation.

Fixes #4430

Verification

• npm --workspace @maka/desktop run build:main — passed
• npm --workspace @maka/desktop run typecheck — passed
• npm run check:app-shell-hooks — passed
• npm --workspace @maka/desktop run check:architecture — passed (60 tests)
• Biome check on the changed TypeScript files — passed
• Relevant Desktop regression suites — passed (16 tests)

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope:

OpenAI Codex assisted with diagnosis, implementation, regression tests, and code review.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Phoenix500526]

@Astro-Han This PR fixes a concrete bug, and AppShell is currently the only composition point that holds both the authoritative archived state and the pending Archive/Delete state, so keeping the small query gate there is the simplest owner-correct fix. The monotonic token ratchet blocks even this composition-only change; moving it into a new helper or controller would add indirection and could make ownership worse, so what path did you intend for legitimate bug fixes that need small AppShell wiring without gaming the metric?

[Phoenix500526]

Hi, @chihumyum This PR currently fails the AppShell architecture ratchet because a narrow bug fix adds query-gate wiring at the composition point. Given the migration tracked in #3439 and the guardrail introduced by #4088, should we hold this fix until the Conversation/AppShell ownership work provides its intended home, or is there an accepted way to land this small wiring now without mechanically moving it elsewhere just to satisfy the ledger?

[chihumyum]

Hi, @chihumyum This PR currently fails the AppShell architecture ratchet because a narrow bug fix adds query-gate wiring at the composition point. Given the migration tracked in #3439 and the guardrail introduced by #4088, should we hold this fix until the Conversation/AppShell ownership work provides its intended home, or is there an accepted way to land this small wiring now without mechanically moving it elsewhere just to satisfy the ledger?

Thanks for raising this. Please do not hold the bug fix until the full Conversation/AppShell migration, and please do not raise the AppShell token baseline.
The ratchet failure is intentional here: deriving archived || pending archive/delete in AppShell introduces automatic-query eligibility policy, rather than composition-only wiring. AppShell being the current rendezvous point for both facts reflects the existing integration knot; it does not make AppShell their final owner.
The bounded path I intended is to put this behind the existing Session catalog/lifecycle authority (session-catalog-state.ts, eventually application/session). That authority should own the archived catalog fact plus scoped Archive/Delete query-block leases. Session Navigation should acquire a lease for the full revision family around the actual Host mutation, while Skills and Plan consume a narrow stable isAutomaticQueryBlocked contract. AppShell should only forward that contract and should lose its pending Set/predicate, so its recorded debt does not grow.
Please also cover revision-family IDs, release on failure/cancellation, refresh after unblocking, and requests already in flight. The bootstrap archived-session filtering can remain as-is.
You are right that the guardrail documentation should state this bug-fix path explicitly; I’ll clarify that separately.

[Phoenix500526]

Hi, @chihumyum This PR currently fails the AppShell architecture ratchet because a narrow bug fix adds query-gate wiring at the composition point. Given the migration tracked in #3439 and the guardrail introduced by #4088, should we hold this fix until the Conversation/AppShell ownership work provides its intended home, or is there an accepted way to land this small wiring now without mechanically moving it elsewhere just to satisfy the ledger?

Thanks for raising this. Please do not hold the bug fix until the full Conversation/AppShell migration, and please do not raise the AppShell token baseline. The ratchet failure is intentional here: deriving archived || pending archive/delete in AppShell introduces automatic-query eligibility policy, rather than composition-only wiring. AppShell being the current rendezvous point for both facts reflects the existing integration knot; it does not make AppShell their final owner. The bounded path I intended is to put this behind the existing Session catalog/lifecycle authority (session-catalog-state.ts, eventually application/session). That authority should own the archived catalog fact plus scoped Archive/Delete query-block leases. Session Navigation should acquire a lease for the full revision family around the actual Host mutation, while Skills and Plan consume a narrow stable isAutomaticQueryBlocked contract. AppShell should only forward that contract and should lose its pending Set/predicate, so its recorded debt does not grow. Please also cover revision-family IDs, release on failure/cancellation, refresh after unblocking, and requests already in flight. The bootstrap archived-session filtering can remain as-is. You are right that the guardrail documentation should state this bug-fix path explicitly; I’ll clarify that separately.

Done