feat: expose durable material-progress state

[timigod]

Linked discussion

Discussion #2690: Workflow: distinguish material agent progress from transport activity

The initial feature-shaped issue #2688 was automatically closed under Paseo's issue-intake policy and redirected to Discussions. This draft now follows that product workflow.

Type of change

• Bug fix
• New feature (with prior discussion + design alignment)
• Refactor / code improvement
• Docs

What does this PR do

This draft exposes a provider-agnostic, read-only materialProgress snapshot through the existing agent protocol and inspect path. It lets an orchestrator distinguish useful output from running/retry/compaction activity without parsing provider-specific logs.

The snapshot reports:

• none, progressing, warning, or stalled;
• completed compactions since the last material event;
• the last material event time and kind when known; and
• a concise classification reason.

The classifier reads a bounded timeline back to the current real-user continuation boundary. Reads, writes, completed tests, decisions, and requested deliverables can count as progress; provider status, retries, commentary, and compaction alone do not.

The branch also makes provider-history trust explicit:

• partial or failed history cannot overwrite the last trustworthy persisted classification;
• live timeline and provider-subagent events are buffered behind normal or forced hydration;
• overlapping hydrations are serialized and rechecked after lock acquisition;
• durable append, delete, and replacement operations are ordered per agent; and
• close blocks new hydration and waits active hydration before persisting and releasing the agent.

The feature is observational only. It does not automatically stop, retry, archive, route, or gate an agent. It contains no Plexer policy, fleet topology, host naming, or machine-local configuration.

This draft is intentionally opened for design and review-shape feedback. I can split protocol/classifier work from the history-lifecycle correctness work if that is easier to review upstream.

How did you verify it

The exact branch tip is 465efcf9d4704ffa515850caedda3b7fa9e5e608, rooted directly at latest stable v0.2.5 (6fc491e6220fba6543bbbe4bf1b1f58cfe59228b).

• 188 focused protocol, CLI, server, storage, classifier, lifecycle, and end-to-end tests passed.
• Full server build passed.
• Server typecheck passed.
• Lint and format checks passed on every touched file.
• The all-workspace pre-commit typecheck passed.
• Independent exact-commit review found no unresolved high or medium issue.
• The exact branch merges mechanically without conflict into upstream main at b6f1274f47ba15eb81010e3ae01291ef5532eeec.

The lifecycle regressions include failed/partial hydration, live-event interleaving before and during hydration, forced replacement, overlapping normal/forced calls, concurrent close, durable mutation ordering, restart trust, and provider-subagent ordering.

No UI or desktop bundle is changed. This stable-derived branch has not been installed or activated on either live daemon.

Checklist

• One focused product capability; EOF recovery and fleet ergonomics are separate.
• npm run typecheck passes
• npm run lint passes
• npm run format ran (Biome)
• UI changes include screenshots or video for every affected platform (not applicable)
• Tests added or updated where it made sense

This contribution was developed with AI assistance; the commands and results above are from actual runs against the exact submitted branch.

[timigod]

Superseded by #2721, which contains only the material-progress protocol, persistence, inspection, docs, and tests. The provider-history hydration, quarantine, and lifecycle work bundled into this draft has been removed into separate independently reviewable units. #2721 preserves an exact-v0.2.5 candidate in ancestry and then integrates current main normally.