refactor(state): decompose listenerMiddleware orchestration without changing lifecycle semantics

[qnbs]

Context

The 2026-09-28 deep audit flagged app/listenerMiddleware.ts as a second high-churn concentration point (~1k LOC, repeatedly touched during persistence/lifecycle work).

Unlike projectFsStore.ts, which already has #554 as a dedicated decomposition owner, listener middleware currently has no focused structural-debt owner.

This issue is post-release and behavior-preserving. It is not permission to redesign persistence, encryption, local-first or AI lifecycle authority.

Goal

Reduce orchestration density and improve auditability by extracting stable, cohesive lifecycle/policy units while preserving every current ordering, retry, cancellation, persistence and error-handling invariant.

Inventory first

Classify current responsibilities, including at minimum:

• project/autosave lifecycle reactions;
• local-first handle reconciliation;
• encryption transition handling;
• factory reset / persistence reset coordination;
• app/window lifecycle flush behavior;
• AI/request lifecycle listeners if present;
• settings-driven side effects;
• native/web-specific side-effect routing;
• diagnostics/error reporting.

For each block classify:

PURE_HELPER_EXTRACTABLE
POLICY_MODULE_EXTRACTABLE
SIDE_EFFECT_ADAPTER
ORDERING_SENSITIVE_KEEP
ATOMICITY_SENSITIVE_KEEP
SEPARATE_EXISTING_OWNER

Invariants

Do not change, implicitly or explicitly:

• stale-writer fencing established by the core(project-boundary): finish current canonical no-loss persistence/import/snapshot closure #553 lineage;
• encryption-transition refusal/remanence semantics, including whatever security(storage): surface local-first clearData wipe failure and prevent encryption-transition remanence #870 establishes;
• reset-gate ordering and IDB quiescence;
• flush-on-quit/final-outcome fences;
• local-first feature-default/opt-in behavior;
• cancellation/supersession contracts owned elsewhere;
• desktop/web authority boundaries;
• user-visible error semantics unless a dedicated issue owns the change.

Extraction strategy

Prefer small mechanical extractions with tests already proving behavior.

Do not split by line count alone. A module may remain large if co-location is required for ordering/atomicity.

Potential end state:

listenerMiddleware.ts
  → registration/composition only

lifecycle/<domain>.ts
  → bounded policies/effects with explicit inputs/outputs

Names/shape are illustrative, not prescribed.

Acceptance

• responsibility/authority map recorded before mutation;
• each extraction has targeted tests around ordering and failure semantics;
• no broad snapshot update used to mask behavior drift;
• no feature work mixed into the refactor;
• full relevant lifecycle/persistence suites remain green;
• before/after complexity and churn surface documented;
• execute only after the v1.29.0 release and higher-priority correctness/toolchain work.

Related: #554, #602, #714, #870, #872.