Separate user-facing metadata from internal metadata in Operation and OperationResult

## Problem

Currently, `Operation` and `OperationResult` expose internal metadata fields (e.g., `metadata.cache.patches`) directly to users. This conflates implementation details with the public API surface, leading to a leaky abstraction.

Additionally, communication between Exchange and framework bindings (e.g., cache incremental update requests) is carried via `OperationResult` with empty `data`, which feels ad-hoc and semantically incorrect.

## Proposal

1. **Separate metadata layers**: Distinguish between user-facing metadata and internal metadata in `Operation` and `OperationResult`. Internal fields like `metadata.cache.patches` should not be part of the public API surface.

2. **Consider a dedicated side channel**: Design an alternative communication mechanism between Exchange and framework bindings for internal signals (e.g., cache incremental update requests) rather than piggybacking on `OperationResult` with empty `data`.

## Motivation

- Cleaner public API — users only see metadata relevant to them
- Internal implementation details can evolve without breaking the public contract
- Eliminates the ad-hoc pattern of sending `OperationResult` with empty `data` for internal communication