v3.1.0 — Issue fixes for 3.0.0

Six issues reported against 3.0.0, all with root-cause analysis good enough to go
straight to the fix. Thanks to @JorisOrangeStudio and @revans-premier-education.

Security

generate no longer bypasses the write gates (#56) — statamic-blueprints generate
calls Blueprint::save(), but the action was in neither write-action list, so it was
gated as a read: a token holding only blueprints:read could create blueprints on
disk, and a site with resources.write => [] could not stop it. It now requires
blueprints:write, passes the resource policy in write mode, and sits behind the
confirmation gate.

This refuses calls that previously succeeded. If you have automation generating
blueprints with a read-scoped token, it needs blueprints:write now.

Fixed

• Cache clearing no longer runs mid-call (#53) — Every write ended in a Stache and
  static wipe run through Artisan inside the request, resetting the in-memory stores
  while the call was still using them. On a live multisite the tree repository returned
  nothing, Statamic padded the empty tree with every entry at root, nested URLs
  flattened and a random entry became the homepage.

  The fix is when, not whether. Removing the clear was tried and abandoned: Statamic
  does not rebuild the indexes that depend on a write, and that list is long — a
  changed max_items leaves an index that later throws, a changed mount leaves every
  entry 404ing, a removed taxonomy leaves whereTaxonomy() returning entries. The clear
  now runs once the tool call is finished. Same coverage, without the mechanism.

• Every tool call starts from fresh request state — Statamic's Blink cache is
  scoped to one request; this server is long-lived, so each call inherited what the last
  one memoized. The second create in a session saw a stale collection tree and was
  saved with uri: null — the entry existed, findByUri() missed it, the page 404'd.

• Blueprint resources are no longer switched off by the writable tool (#54) — Reads
  now have their own resources.enabled. If you used
  STATAMIC_MCP_TOOL_BLUEPRINTS_ENABLED=false to deny blueprint access entirely, set
  STATAMIC_MCP_RESOURCES_ENABLED=false as well.

• Resource refusals no longer arrive as HTTP 500 (#55) — They became -32603, which
  a hosted client behind a proxy showed as a bare 502 with the message gone. Expected
  conditions now travel as a normal result carrying the reason.

• content_validate is usable again (#57, #58) — Every dated entry reported a
  missing date, and every max_items: 1 relationship failed twice, on content that
  validates fine in the Control Panel.

Full detail, including why several of these fixes were themselves wrong the first time,
in CHANGELOG.md.