docs: add toolkit-consumer guide — "building on mecatl"

Problem

The existing docs serve two audiences well: operators (docs/usage/ — how to run mecated, every flag, the APIs) and contributors (docs/architecture/ — how the internals work). There is nothing aimed at a third audience: toolkit consumers — teams or projects that want to build a product on top of mecatl.

This is the gap we'd point external developers at if the project were public, and it's already a gap felt internally when onboarding new surfaces (see the scheduler discussion in #189).

What the missing guide should cover

What you get out of the box — a curated tour of the loop, core tools, permission model, hooks, resilience, observability, memory, and MCP from the perspective of "here's what you don't have to build."

The extension points — which ports you implement and what each one buys you:

• port.LLMProvider — bring your own model backend
• port.SessionStore + port.EventLog — bring your own persistence (jsonl / Redis / gRPC driver)
• port.SessionLease — bring your own distributed locking (flock / k8s / gRPC driver)
• port.HookRunner — hook into the lifecycle
• port.PermissionPolicy — custom permission logic
• Tool catalog seam — add tools, expose MCP servers, package skills
• Agent definitions — named specialist agent profiles

Deployment shape decision tree — the most useful thing a new consumer needs and the thing most scattered across ADRs today:

• Embed engine/ directly (own the composition, tiny dep closure)
• Drive mecated or mecak8s over gRPC/HTTP (you're a client)
• Start from mecak8s for cloud-native (Redis + k8s lease pre-wired)
• Use mecatequi for single-shot CI/headless (one prompt → patch + exit code)
• Mix-and-match: any binary with custom store/lease adapters injected

Cloud-native kit properties — what "disposable process, externalized state, durable record" means practically, what you get for free, and what you need to wire up.

Related

• #189 (scheduler) surfaces this: the cloud-native kit properties are relevant to how a consumer thinks about scheduling, session ownership, and load distribution — but there's nowhere to point them.
• engine/COMPATIBILITY.md and engine/CHANGELOG.md govern API stability but don't explain why a consumer would import the engine module vs. running a binary.

Note: mecatl.dev has been registered in case the project is open-sourced under that name — these docs would be the primary thing to point external users at.