Add MCP elicitation for confirmation before mutating and destructive tool calls

## Problem

MCP tools identify mutating and destructive operations, but the server does not request user confirmation before executing them. An agent can submit an authorized operation without a client-mediated confirmation step. Elicitation must complement, not replace, RBAC, profile opt-in, and audit controls.

## Evidence

- `src/kdive/mcp/tools/_docmeta.py:37-69` defines destructive tool names and mutating/destructive annotations; these are hints, not a confirmation gate.
- `src/kdive/mcp/assembly/app.py:61-89` assembles the MCP app and middleware without an elicitation/confirmation component.
- `src/kdive/mcp/tools/lifecycle/control/registrar.py:713-750` registers `control.force_crash` and calls its handler without requesting confirmation.
- `src/kdive/mcp/tools/lifecycle/systems/registrar.py:415-444` likewise dispatches `systems.teardown` directly. Its existing project-admin authorization remains necessary.

## Expected

For covered mutating and destructive MCP calls, the client presents the operation and target to the user before any state change or job enqueue. Only an affirmative response for that exact call permits execution. Decline, cancellation, timeout, malformed response, or lack of supported elicitation leaves the operation unexecuted with an actionable result. Replayed requests must not turn an earlier confirmation into approval for a different operation or target.

## Proposed approach

Design one tool-call admission path using the existing tool classification, including `tools.invoke`’s resolved inner tool, so confirmation cannot be bypassed through the gateway. Bind the prompt to the effective operation and relevant arguments; keep existing authorization and destructive-op checks in force. Specify the supported MCP protocol/client capability path before implementation: [MCP 2026-07-28 uses multi-round-trip `input_required` for elicitation](https://blog.modelcontextprotocol.io/posts/2026-07-28/), while this checkout pins `fastmcp-slim==3.4.4` and `mcp==1.28.1` (`pyproject.toml:14,23`). Do not treat a client-supplied acceptance as an independent security principal.

Cover accept, decline, cancel, unsupported client, replay, gateway dispatch, and authorization denial in tests. Update agent-facing tool contracts and generated reference documentation for the resulting behavior.

Start by reading src/kdive/mcp/tools/_docmeta.py, src/kdive/mcp/assembly/app.py, and the control and systems registrar ranges cited in the issue, then check the pinned fastmcp-slim and mcp versions in pyproject.toml. Establish the supported elicitation capability path before implementation and trace gateway dispatch through tools.invoke. Done means covered calls cannot bypass confirmation, all listed outcomes are tested, existing authorization remains enforced, and tool contracts and generated reference documentation are updated.

Written by the indexing model from the issue text.