ACP server ignores the configured provider, hardcodes tool kind, and its unknown-session fallback always raises #120

Testing Mini-Agent's ACP server against a third-party ACP client turned up three
defects in mini_agent/acp/. All are reproduced below on main (d76a4f638968),
Python 3.12, agent-client-protocol 0.12.1.

Note: reaching any of this first requires pinning mcp==1.9.4, per #119 -- with the
resolved mcp 2.x the package does not import at all. That one is already tracked,
so it is not repeated here.

1. The ACP server ignores the configured provider, so any OpenAI-wire endpoint 404s

mini_agent/acp/__init__.py:186 constructs the client without provider:

llm = LLMClient(api_key=config.llm.api_key, api_base=config.llm.api_base,
                model=config.llm.model, retry_config=...)

LLMClient.provider defaults to LLMProvider.ANTHROPIC, and the module never imports
LLMProvider at all. The CLI does derive it (mini_agent/cli.py:559):

provider = LLMProvider.ANTHROPIC if config.llm.provider.lower() == "anthropic" else LLMProvider.OPENAI

So provider: "openai" is honoured by mini-agent and silently ignored by
mini-agent-acp: the ACP server posts Anthropic-shaped requests at an
OpenAI-compatible endpoint and every turn fails.

Reproduction -- one config.yaml, two entry points:

api_key: "<key>"
api_base: "https://api.deepseek.com/v1"
model: "deepseek-v4-pro"
provider: "openai"

$ mini-agent -w /tmp/demo -t "Read hello.txt and reply with its exact contents."
  -> works: 1 tool call, correct answer

$ mini-agent-acp        # same config, driven over ACP
  -> Error: Retry failed after 4 attempts. Last error: Error code: 404

I verified this is not the /v1 suffix question from #37: the CLI succeeds with
api_base both with and without /v1, and the ACP server fails with both.

Fix (verified locally -- the same prompt then returns the correct answer over ACP):

-from mini_agent.llm import LLMClient
+from mini_agent.llm import LLMClient
+from mini_agent.schema.schema import LLMProvider

 llm = LLMClient(api_key=config.llm.api_key, api_base=config.llm.api_base,
                 model=config.llm.model,
+                provider=(LLMProvider.ANTHROPIC if config.llm.provider.lower() == "anthropic"
+                          else LLMProvider.OPENAI),
                 retry_config=...)

2. Every tool call is reported to the client as kind="execute"

mini_agent/acp/__init__.py:152:

await self._send(session_id, start_tool_call(call.id, label, kind="execute", raw_input=args))

The kind is a literal, so a file read, an edit, a search and a shell command are all
announced identically. The ACP schema defines ten kinds
(read, edit, delete, move, search, execute, think, fetch,
switch_mode, other), and clients group, label and icon tool calls from this field.

Observed frame for a plain file read -- the title already knows the right answer
while kind does not:

{"sessionUpdate": "tool_call", "kind": "execute",
 "title": "read_file(path='hello.txt')", "rawInput": {"path": "hello.txt"}}

A client that renders kind (the spec field) therefore shows every read as an
execution. Mapping the tool name onto the closer kind, with other as the fallback,
would fix it.

3. The unknown-session fallback in prompt() always raises

prompt() handles a missing session id like this:

# Auto-create session if not found (compatibility with clients that skip newSession)
new_session = await self.newSession(NewSessionRequest(cwd=None))

NewSessionRequest requires cwd: str and mcpServers, so this call fails validation
on every invocation and the recovery path has never run.

Reproduction -- initialize, then session/prompt with an id that was never created:

{"code": -32602, "message": "Invalid params", "data": {"errors": [
  {"loc": ["cwd"], "msg": "Input should be a valid string", "input": null},
  {"loc": ["mcpServers"], "msg": "Field required"}]}}

So a client that loses its session gets a confusing complaint about cwd rather than
"unknown session". Worth noting the intended behaviour is also questionable: had the
call succeeded, cwd=None would fall back to config.agent.workspace_dir rather than
the directory the client asked for, so the agent would silently operate somewhere
else. Returning a clear error for an unknown session seems better than reviving the
fallback.

Smaller things noticed while reading

• self._sessions is never evicted, so an Agent (with its full message history) is
  retained per session for the process lifetime.
• initialize ignores params entirely, so clientCapabilities are never read (the
  client's fs/terminal cannot be used) and the protocol version is echoed rather
  than negotiated.
• AgentCapabilities(loadSession=False) is hardcoded and no loadSession /
  authenticate / setSessionMode methods exist. That is a fair description of what
  is implemented; flagging it only because clients use loadSession to decide whether
  a session handle can be reused, so Mini-Agent is treated as single-turn by clients
  that gate on it -- even though prompting one sessionId twice does hold context
  correctly, which I confirmed.
• README.md links "ACP" to modelcontextprotocol/protocol; the code implements
  Zed's Agent Client Protocol (agent-client-protocol), which is a different spec.
• pytest, pip and pipx are listed in [project.dependencies] rather than as dev
  extras.

Happy to open a PR for 1 and 2 if that is useful.