Design optimistic updates for HTTP mutations

## Summary

Design optimistic updates for HTTP mutations only after retry/refetch requirements and real application use cases are established.

An optimistic mutation updates local query data before the remote operation completes, then either commits the server result or applies an explicit rollback message. This interacts with concurrent mutations, invalidation, refetch, stale responses, and retrying non-idempotent operations.

The framework does not promise exactly-once execution, automatic rollback, or atomicity between external effects and message delivery. An optimistic-update design must preserve that negative space rather than imply transactional guarantees.

## RFC requirements

- Define ownership and versioning of optimistic state.
- Define ordering for overlapping mutations of the same query key.
- Define how invalidation and refetch interact with pending optimistic values.
- Require explicit application-visible rollback/repair messages.
- Define stale success and stale failure handling after a newer mutation wins.
- State how retry policy affects non-idempotent mutation effects.

## Acceptance criteria

- [ ] At least one real application use case and rollback model are documented.
- [ ] Retry and explicit refetch requirements are settled first.
- [ ] An RFC defines concurrency, rollback, invalidation, and stale-result semantics.
- [ ] Tests cover overlapping success/failure orders and cancellation.
- [ ] Public documentation states that exactly-once execution and automatic rollback are not guaranteed.