Migrate Elicitation to MRTR and verify legacy back-compat

Migrate Elicitation to Multi Round-Trip Requests (MRTR) and verify back-compat

Part of #481.

Elicitation is used for destructive-op confirmation:

• DotNetCliTools.Project.Consolidated.cs (server.ElicitAsync(...))
• DotNetCliTools.Solution.cs (server.ElicitAsync(...))

Under 2026-07-28, server→client requests (elicitation/sampling/roots) are removed and replaced by declarative MRTR inputRequests/inputResponses. The SDK ships a back-compat resolver, so existing ElicitAsync calls should keep working on legacy connections.

Tasks

• Verify ElicitAsync confirmations still function via the SDK back-compat resolver on legacy clients.
• Evaluate adopting MRTR inputRequests so confirmations also work natively on pure 2026-07-28 clients.
• Confirm the round-trip cap (10) does not affect the simple confirm flow.

Acceptance

• Destructive-op confirmation works on both legacy and 2026-07-28 clients (or a documented limitation if MRTR adoption is deferred).

Start with DotNetCliTools.Project.Consolidated.cs and DotNetCliTools.Solution.cs, then inspect how their server.ElicitAsync(...) calls interact with the SDK back-compat resolver. Exercise destructive-operation confirmations on legacy and 2026-07-28 clients, and check whether the 10-round-trip cap affects the flow. Done means both client types work, or the deferred MRTR limitation is documented.