Render ACP elicitation forms

[OSadovy]

Implements #792.

The code is mostly AI-written. I've been using it daily since and have tested the behaviours below against a live agent, so I'll vouch for it working.

What it does

• Advertises elicitation.form in initialize. url is not supported yet.
• Renders elicitation/create as an in-buffer form covering every ElicitationPropertySchema variant, both spellings of each enum shape (oneOf/enum, items.anyOf/items.enum), and the forward-compat unknown type.
• Validates required-presence on submit only; minLength, pattern, minimum, minItems and friends are not implemented yet - left for the agent to reject.
• TAB walks the form as one more item kind beside prompts, blocks and permission buttons; RET acts. Named commands reading text properties rather than per-control closures (Expand/collapse group with TAB #759).
• Reports blocked while a form is pending, so a queued prompt isn't steered into a turn that's waiting on an answer.
• Cancels pending forms on interrupt, and arms the same idle timer an unanswered permission does.

Slightly opionated behaviour that isn't obvious

• The free-text "Other" field folds into the select it belongs to. Agents bridging an ask-the-user tool send a select plus a companion text field, marked with an un-namespaced _meta key. Rendered as two independent fields, one question reads as two and can be answered twice in contradictory ways.
• On a single-select the two replace each other; on a multi-select they combine into one string. Those agents read the companion first and return early, so a response carrying both silently loses the ticks - verified against the Claude adapter. AFAIK Zed is not doing it - we can do better here.
• A checkbox answers only when ticked, required, or carrying a default. An unticked optional box is indistinguishable on screen from one nobody reached. Same rule Zed's form uses.
• Integer fields reject a fraction rather than truncating it, and each retry is prefilled with the text that was rejected.
• An elicitation with no tool call behind it - from an MCP server, or scoped to a request rather than a session - keeps its settled form, which is the only record of what was asked.
• Option previews open from the option (?) or its disclosure glyph, and are offered as help-echo so C-h . reads them without opening. ? is bound only on options that actually carry a preview, so it stays free everywhere else - the viewport still opens its help menu with it. That _meta key is agent-namespaced, so previews are Claude-only and their absence changes nothing.

Incidental fixes

Happy to submit those as separate PRs.

• agent-shell-ui--echo-action-hint takes a command and keymap, so chrome bound to its own map names its own key.
• A fragment no longer erases the help-echo its body's content carried - it set the property to nil whenever debugging was off.

Not included

url mode; constraint validation; digit shortcuts; eldoc.

Where this differs from #792

I wrote the issue before building any of it, and a few things changed on the way.

• Options aren't numbered and there are no digit shortcuts - the digits are already taken in the viewport map, and without them the numbering is just noise.
• "Other" is a minibuffer read rather than an editable field inline in the buffer. An editable region inside otherwise read-only rendered text is a lot of machinery for one field, and the form re-renders on every interaction, which would fight it.
• TAB stops on every control rather than jumping question to question.
• A cancelled form shows Cancelled without preserving whatever had been typed into it.
• No SVG radio/checkbox markers - text only for now.

One question

acp-make-initialize-request hardcodes clientCapabilities to the fs pair, so there's no way to advertise elicitation through it. I build the request locally instead (agent-shell--make-initialize-request), which does mean agent-shell no longer picks up future changes to that constructor. Would you rather acp.el grew a capabilities argument? Happy to send that first and keep using the helper here.

Checklist

• I agree to communicate (PR description and comments) with the author myself (not AI-generated).
• I've reviewed all code in PR myself and will vouch for its quality.
• I've read and followed the Contributing guidelines.
• I've filed a feature request/discussion for a new feature.
• I'm making visual changes, so I'm including screenshots so you can view and discuss.
• I've added tests where applicable.
• I've updated documentation where necessary.
• I've run M-x checkdoc and M-x byte-compile-file.