ACP sessions can go quiet early for openai-codex / multi-phase agent workflows

## Summary

Hermes / OpenAI Codex sessions in the ACP Client can appear to go quiet before the overall task is actually complete.

After investigating the installed ACP Client behavior and VS Code logs, this looks like a combination of:

1. no workflow-level continuation/watchdog in the ACP Client after a prompt turn ends, and
2. VS Code host-side in-progress reporting warnings for unknown session types like `openai-codex`.

This is particularly noticeable for agent workflows that are intentionally multi-phase (for example a Lead / PM agent that plans, delegates, validates, and verifies), where a single ACP prompt finishing does **not** necessarily mean the overall job is complete.

## Observed behavior

In VS Code, a Hermes-backed session can:
- stream output normally
- then stop updating
- while the user expectation is that the agent should continue autonomously until the task is actually done

The extension/UI then feels like it has “gone quiet” before work is complete.

## Evidence

### VS Code renderer warnings

Repeated warnings appear in `renderer.log`:

```text
Attempted to report in-progress status for unknown chat session type 'openai-codex'
Attempted to report in-progress status for unknown chat session type 'claude-code'
Attempted to report in-progress status for unknown chat session type 'copilotcli'
Attempted to report in-progress status for unknown chat session type 'copilot-cloud-agent'
```

This suggests the surrounding VS Code chat/progress UI is not recognizing these session types for in-progress reporting.

### ACP Client prompt lifecycle

From the installed ACP Client source map / code:

- `SessionManager.sendPrompt()` sends exactly one ACP `prompt()` call and returns the single `PromptResponse`
- `ChatWebviewProvider.handleSendPrompt()`:
- posts `promptStart`
- awaits the one `sendPrompt(...)`
- posts `promptEnd`
- there is no workflow-level continuation/watchdog loop after prompt completion

In other words, the client behaves like a one-turn ACP wrapper, not a workflow-aware supervisor.

## Why this matters

For coding agents that use multi-step orchestration (Lead / planner / verifier style workflows), a prompt returning a normal `stopReason` is not always equivalent to “the job is complete.”

Without some notion of:
- in-progress state that survives beyond a single text burst
- or a workflow-aware continuation / resume mechanism

…the session can appear to terminate early from the user’s point of view.

## Suspected root cause

Likely two related issues:

1. **ACP Client gap:** no higher-level continuation/watchdog logic after a turn completes
2. **VS Code host integration gap:** unknown chat session types (`openai-codex`, etc.) do not participate correctly in in-progress reporting

## Reproduction (high level)

1. Connect ACP Client to an ACP-compatible coding agent that identifies/behaves like `openai-codex`
2. Start a task that is intentionally multi-phase / long-running (for example an orchestration workflow)
3. Observe that the UI can stop updating after a prompt turn completes, even though the user expectation is that the workflow should continue until completion
4. Check `renderer.log` for warnings about unknown chat session types

## Expected behavior

At minimum:
- the UI should reliably show in-progress state for these session types
- the session should not appear “done” purely because one ACP prompt turn returned

Potentially:
- the extension may need a workflow-aware continuation strategy, or at least a better surfaced “agent still active / more work expected” state

## Notes

This report is intentionally focused on diagnosis rather than prescribing a specific fix implementation.

The strongest concrete signal so far is the renderer warning about unknown chat session types combined with the ACP Client’s one-prompt / one-promptEnd lifecycle.

Start with the ACP Client source map/code around SessionManager.sendPrompt() and ChatWebviewProvider.handleSendPrompt(), then inspect renderer.log for the unknown session-type warnings. Trace how promptStart, the single prompt response, and promptEnd determine visible progress. Done should be defined as a concrete change that keeps multi-phase work accurately represented without treating one returned prompt as overall completion.

Written by the indexing model from the issue text.