4. What the user sees, and what waits for the server

The Model shows a durable edit before the server has it. For most UI that is the point. Two things need more:

• A refused edit. It comes back as a rejection on the next exchange, the replica drops it, the mount re-installs the slice, and the field reverts. replica.status.rejected names the operation, with the server's reason when it gave one (an authorize rule's { allowed: false, reason }), so the UI can say why. onPersistenceFailure does not run for this; the local save succeeded.
• Something that must not claim success early. An agent tool, a "shared with the team" confirmation. These wait on mounted.committed, the slice as the server confirmed it, with no pending edit applied:

import { Agent } from 'foldkit-agent'

const TodoAgent = Agent.forApplication(App)
const agent = TodoAgent.make({
  messages: TodoAgent.expose(Message, {
    CreatedTodo: {
      name: 'create_todo',
      description: 'Create a shared todo',
      completion: Agent.when({
        source: mounted.committed,
        predicate: (shared, request) => shared.todos.some(todo => todo.id === request.id),
      }),
    },
  }),
})

That completes after the exchange that commits the todo, and never for one the server rejects. The agent learns nothing about cursors or operations. Remote draws the same line over its own cache; see what a reader sees while a change is in flight.