Guard rails for destructive REST actions

The plugin exposes the whole REST API through one ability, `rest-api/call`. A harness that gates MCP tools by name can only allow or deny everything at once. There is no way to let reads through and hold back writes and deletes.

WordPress capabilities stay the only thing that decides what a user may do. This work adds a layer on top: it lets a harness express different policy per action, and it nudges a model to confirm before changes that affect the live site.

Tracking issue for a five-part series:

- [x] #29 — Deny permission for unmatched routes
- [x] #30 — Split `rest-api/call` into `rest-api/read`, `rest-api/write`, `rest-api/delete`
- [x] #31 — Route risk classification and confirmation guidance
- [x] #32 — Filterable policy layer, permissive by default
- [ ] #33 — Research spike: elicitation-based confirmation (no implementation yet)

Each ships as its own PR.

Treat this as the parent tracking issue: review the completed #29–#32 entries and focus on the unchecked #33 research spike. Start from the stated elicitation-based confirmation requirement; completion is a research outcome, since the issue explicitly says no implementation yet.

Written by the indexing model from the issue text.