MCP server should call `pkg/functions` directly, not shell out to the `func` binary

## Summary

The MCP server (`pkg/mcp`) currently exposes Functions to AI agents by shelling out to the `func` binary as a subprocess. This was an expedient — it let the MCP surface land quickly by piggy-backing on the existing CLI. It should be replaced with direct use of the core library at `pkg/functions`, in the same way the CLI itself does.

## Architectural principle

The real logic of Functions lives in `pkg/functions` (and friends — `pkg/k8s`, `pkg/docker`, `pkg/knative`, etc.). The `cmd/` package wraps that library as a CLI. The `pkg/mcp` package should wrap the same library as an MCP server.

```
┌──────────────┐
│ pkg/functions│ ← core: where the logic lives
└──────┬───────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌──────┐
│ cli │ │ mcp │ │ ... │ (future surfaces)
└─────┘ └─────┘ └──────┘
```

Today's reality is the bottom-left arrow points sideways — `pkg/mcp` calls into `cli`, which calls into `pkg/functions`. That extra hop is a leaky abstraction.

## Why this matters now

- Every MCP tool handler runs `exec.Command("func", ...)`, captures stdout/stderr blobs, and either passes the text to the agent verbatim or tries to parse it. The parsing is brittle (see #3753 for a worked example), the structured-output story is thin, and adding any tool requires routing through an `executor` interface that has been growing leaky over time (e.g., the recently-proposed `ExecuteRaw` in #3752).
- Subprocess overhead is real (~100ms+ per MCP call just to fork `func`).
- Error propagation is constrained to exit codes + text scraping rather than the rich typed errors that already exist in the Go API.
- The in-process API gets exercised consistently by both consumers, surfacing bugs and API gaps faster.

The TODO comment already in the tree at `pkg/mcp/mcp.go:154-155` flags exactly this direction.

## Scope

- Replace every MCP tool handler in `pkg/mcp/tools_*.go` with direct calls into `pkg/functions` (and `pkg/k8s`, `pkg/docker`, etc. where appropriate).
- Drop the `executor` interface and its mocks once all handlers are migrated.
- Replace text-blob results with typed values flowing into `CallToolResult.StructuredContent`.
- Error mapping uses Go's typed errors (`errors.As`) rather than substring matching.

## Phased migration suggested

1. Add an interim adapter that lets shellout-backed and library-backed handlers coexist (so we can land one tool at a time without breaking the others).
2. Migrate read-only tools first (`list`, `describe`, `healthcheck`, `check_prerequisites` if that lands first via #3749 / #3752) — lowest risk, easiest to validate.
3. Migrate mutating tools (`build`, `deploy`, `delete`, `config_*`).
4. Remove the `executor` interface, its mocks, and the `func` binary as a runtime dependency of the MCP server.

## Open design questions

- **Long-running operations** (`func deploy`, `func logs`): how do we surface progress events to the agent? MCP supports progress notifications via the protocol; the in-process API would need to emit these.
- **Interactive prompts**: `func` has prompt flows; MCP context never has a TTY. Handlers must either resolve prompts via the request payload or fail cleanly.
- **Testing surface**: the current `executor` mock made it easy to test handlers in isolation. The replacement is to inject the same `pkg/functions` client or its interfaces — most of which already exist as injectable points.
- **Concurrency**: the CLI assumes one operation per process; direct library use means handlers may run concurrently. Review `pkg/functions` for thread safety where MCP would call into it from multiple goroutines.

## Relationship to other work

- **#3769** (`--json` output for every `func` subcommand) remains valuable — for scripts, CI, third-party tools, and IDEs that drive `func` as a subprocess. It is not blocked by this issue and does not block this issue.
- **#3770** (MCP consume `func --json` and forward via `StructuredContent`) **is superseded by this issue**. If `pkg/mcp` calls `pkg/functions` directly, there is no `func --json` subprocess output to consume.
- **#3752** (`check_prerequisites` tool): a current-day example of the friction this issue resolves — needed to add `ExecuteRaw` to the executor to shell out to `docker`/`kubectl`. Once the MCP server uses `pkg/functions` and `pkg/k8s` directly, the same checks become idiomatic Go.
- **#3750 / #3753** (structured error categories): becomes a non-issue. Typed errors from `pkg/functions` reach MCP handlers directly; categorization is a pure mapping, not a parsing problem.

## Non-goals

- Removing the `func` CLI. The CLI is the primary human-facing surface and stays as-is.
- Removing the MCP server's *behavior*. Tools keep the same names, inputs, and observable outputs. This is internals only.