MCP server: add delete_frame tool (RBAC-gated)

Motivation

#51 added create_frame and update_frame and deliberately left deletion out: a destructive, model-invokable operation deserves its own decision about confirmation semantics rather than riding along with the write PR.

Everything needed already exists. DeleteFrame is implemented and gated on rbac.PermDelete, and it already refuses to delete a Frame that is referenced as a parent unless the caller force-cascades (backend/internal/frames/admin.go, DeleteBlocked in proto/frames/v1/frame_service.proto).

Questions to settle first

• Should force-cascade be reachable over MCP at all? Cascading a delete through children is the most destructive operation in the product. A reasonable position is that delete_frame supports only the non-cascading case and tells the caller to use the web app or CLI when the Frame has children.
• Is a text confirmation meaningful? An AI client can trivially satisfy any confirm: true field, so it is closer to documentation than a safeguard. Worth deciding whether it earns its place.
• Recoverability. Versions are retained per Frame, but confirm whether a deleted Frame is recoverable at all; if it is not, that raises the bar for exposing it here.

Implementation notes

The seam from #51 applies directly: add a DeleteFrame-shaped method to the FrameSource interface in backend/internal/mcp/resources.go, register the tool in getServer alongside the others, and map the existing error codes through writeErrorText (which already handles FailedPrecondition). No change to frames.Service should be needed - if one appears necessary, that is a sign the RBAC path is being bypassed.

Test coverage should mirror TestMCPWritesEnforceRBAC: a caller without delete permission is denied, the owner succeeds, and a Frame referenced as a parent is blocked with a clear message.

Start by reviewing backend/internal/mcp/resources.go, getServer, writeErrorText, and the existing TestMCPWritesEnforceRBAC coverage. Before implementation, resolve the force-cascade, confirmation, and recoverability questions, then trace DeleteFrame in backend/internal/frames/admin.go and its proto error definitions. Done means the MCP tool follows the chosen safety semantics and covers denied, permitted, and parent-referenced deletion cases.