Support generic ACP elicitation/create separately from tool permission approval

[rpelevin]

I am carrying this over from the old adapter because generic elicitation and tool permission approval should stay semantically separate in the new Codex ACP server.

Current desired behavior:

When an ACP client advertises generic elicitation capability, the adapter should forward supported structured input requests as generic elicitation requests rather than treating them as tool approvals or auto-declining them. Tool permission approval should remain a separate authorization path tied to one pending tool invocation.

The boundary I would want is:

1. Generic form or URL elicitation asks the user for structured input and returns structured input.
2. Tool permission approval asks whether a specific pending tool call may run.
3. A generic elicitation response can never approve a tool call.
4. A tool approval response is correlated to the original permission request id, tool identity, call id, and argument digest.
5. Persistence options for approval lifetime do not apply to arbitrary form submission unless a separate generic persistence model exists.

The regression shape I would add is:

1. Unsupported generic form elicitation is declined without breaking tool approval handling.
2. A supported form elicitation round-trips a schema-shaped response through the ACP client.
3. A URL completion cannot satisfy or approve a pending tool call.
4. A tool approval response with a stale or mismatched request id fails closed.
5. A permission decision and a generic form response are both visible in the transcript as different semantic event types.

Boundary: architecture and test feedback only; no claim about using this project or running its code.