rustmistmcp v0.3.0

Changed

• Systemd unit documentation (mecmcp#354). Added a comment explaining the
  fleet seccomp posture: SystemCallErrorNumber=EPERM returns EPERM rather than
  raising SIGSYS and killing the process mid-request, which is what happened to
  rustunifimcp during a change-set state write (mecmcp#351). An EPERM denial is
  silent at the systemd layer and can become visible only if the application
  stops discarding the errno.

Added (from RC)

• An approval now binds the preview it was shown. mecmcp 0.23.0 adds a v5
  approval digest that carries the stored preview's digest, and this server does
  store a preview, so approvals are signed with v5 rather than v4. An approver
  now vouches for the exact preview they saw, not merely for the plan, and the
  coordinator refuses any later write that swaps or drops that preview.

Changed

• Re-pinned the mecmcp-* crates from v0.21.0 to v0.23.0, spanning two
  minors, and updated the pinned upstream revision in the workspace contract
  test from dbae2e38 to d61867d7.
• The apply takes claim_change_set_for_apply instead of writing
  Approved -> Applying itself. 0.22.0 made the claim the only legal route onto
  that edge -- it does the read and the write under one lock, so two applies
  cannot both read Approved and both issue the write -- and the plain
  update_change_set this used is now refused outright. ApplyHandle::None,
  because a Mist write is synchronous and returns no pollable handle: a crash
  mid-apply leaves an outcome only the service knows, which is what
  apply_without_handle records honestly.
• The drift-detection path claims before settling. It wrote Approved -> Failed
  directly, which 0.22.0's transition policy refuses; the refusal was swallowed
  into an audit line, so a drifted change set stayed Approved and its stale
  approval remained spendable. It now claims first -- nothing has been sent to
  Mist at that point -- which gives the settle a legal Applying -> Failed and
  spends the approval, so a drifted plan cannot be retried. That claim uses
  ApplyHandle::Expected, the opposite of the apply path, and for the opposite
  reason: the marker decides how a crash is read back, and on this branch
  nothing was sent, so recovering to Failed states the truth. Handleless would
  strand a record known not to have run.
• ChangeSetRecord literals carry the new apply_without_handle field.
• jsonschema bumped from 0.50.1 to 0.51.0.
• toml bumped from 0.8.23 to 1.1.4+spec-1.1.0, and the workspace-contract
  test now uses toml::from_str instead of str::parse, as toml 1.x changed
  the FromStr implementation on Value to stop after the first table header.

Performance

• Compiled JSON Schema validators are now cached (#59). Request and response
  validation previously compiled the schema on every call — roughly 2.2 MB cloned
  from the components registry, then compiled, then dropped. Measured against the
  pinned catalog (1059 operations, 4.6 MB source):

  stage	before	after
  per call, uncached	63.25 ms	1.14 us
  first call	~100 ms	~100 ms

  Per-call validation drops from 63 ms to 1 us, a ~55,000x speedup for cached
  validators. The catalog is immutable once parsed, so compiled validators are
  memoised. Cache misses race harmlessly: concurrent compilations of the same
  schema may occur, with the first insert winning. Compile failures are not cached,
  keeping catalog defects visible rather than frozen.

  The cache key includes operation name, parameter location and name, and for
  responses both status code and media type, ensuring distinct schemas never
  share a cache entry. This addresses the known issue (#59) noted in v0.2.0.

Fixed

• Dependabot no longer attempts to bump the git-pinned mecmcp crates (#69).
  Weekly cargo runs were failing because dependabot advanced the mecmcp-* refs
  from pinned tags to mecmcp main, but the exact version requirements then
  refused the untagged commits. The mecmcp version is deliberately moved by hand
  in a single chore/mecmcp- PR that re-pins every file at once, so
  dependabot is now configured to ignore those crates.

Security

• Moved off the yanked chacha20 0.10.1. The supply-chain gate went red when
  chacha20 0.10.1 was yanked upstream. This is a transitive dependency through
  rand -> rmcp -> mecmcp-server, so nothing here selects it directly. The
  lockfile now pins the compatible 0.10.2 release.

Upgrading

• A binary-only rollback to a build pinned at mecmcp v0.21.0 will refuse to
  start once any change set has been approved under this one. A v5 approval
  forces the change-set state file to schema 6, which the v0.21.0 reader does
  not accept -- correctly, since it cannot verify what it cannot parse. Roll the
  state file back with the binary, or restore a pre-upgrade snapshot.

Full changes: v0.2.0...v0.3.0

Backfilled GitHub release for an existing tag (2026-10-07).