feat(plugin): operation maps on invocation hooks

[wangyb-A]

Closes #617.

What

The invocation-level plugin info objects carried no view of the execution's
operation state, so Python plugins could not see what the JS SDK exposes on
every invocation hook.

• InvocationInfo.operations — the checkpointed operation map converted to
  OperationInfo, on invocation-start and invocation-end. Mirrors JS, where
  it sits on InvocationBaseInfo.
• InvocationStartInfo.updated_operations — the subset named by the durable
  invocation input's UpdatedOperationIds, i.e. operations completed externally
  while the execution was suspended. Start hook only, matching JS's
  InvocationInfo.updatedOperations.

Both are kw-only with empty-map defaults, and repr=False, compare=False, hash=False, so existing plugins, hook constructors and positional callers are
unaffected.

Notable decisions

• The end hook re-reads the operation map rather than reusing the
  start-of-invocation snapshot. This matches JS, which overrides
  operations: toOperationInfoMap(...) at every onInvocationEnd site, and it
  is strictly more informative — the suspending invocation reports 1 operation
  at start and 2 at end.
• Snapshot eagerly, convert lazily. Plugin invocation hook infos missing operations and updated-operations maps #617 suggested lazy construction for
  operation-heavy executions. Fully lazy was wrong: a plugin that stashes the
  info and reads it later would observe a later state than its own hook. So
  the raw map is snapshotted when the hook fires (a cheap dict copy) and only
  the per-operation OperationInfo conversion is deferred and cached. A unit
  test pins this.
• The lazy view is copy-safe. It holds no lock — building the map is pure
  and idempotent, so a race can only duplicate work — and implements
  __deepcopy__ to materialize a plain dict. Without that, the lock made
  dataclasses.asdict(info) and copy.deepcopy(info) raise TypeError, and
  because plugin exceptions are swallowed a plugin that serialized an info would
  have its hook silently dropped. (This was the Codex finding on feat(plugin): operation maps on invocation hooks #623.)
• The maps are additive, like the payload fields in fix(plugin): make payload fields additive on hook infos #627: mapping-valued
  fields in the generated __hash__ would make a previously hashable
  InvocationStartInfo raise TypeError, and their entries carry operation
  results and errors that instrumentation logs wholesale through repr. fix(plugin): make payload fields additive on hook infos #627's
  test caught this the moment these commits were rebased onto main.
• is_replayed is left False on map entries, matching JS's
  toOperationInfoMap (isReplay: false) — these describe stored state, not
  replay events.

Testing

• 1538 unit tests passing; hatch fmt --check clean.
• Live plugin conformance suite (us-west-2), with the conformance handlers
  applied: 23/23, exit 0 — 10-19 flips PASSED with no change to the
  requirement, and 10-1..10-18 / 10-20..10-23 are unaffected. That was
  measured before this rebase; the handlers themselves are in the separate
  conformance PR (Add hook-info field-shape conformance handlers #615, also closed by accident) and are still needed to
  re-verify end to end.

Known pre-existing flake (not from this change)

One earlier suite run showed 10-22 (PluginOperationChangeShape) red; an
immediate re-run on byte-identical code was 23/23 clean. The only edit on that
path here is a pure refactor (an inline dict comprehension replaced by
_to_operation_info_map, the same conversion), and 60/60 local in-process
repeats of the 10-22 handler satisfy its primary matcher. JS's handler for that
requirement is structurally identical, so it is likely cross-SDK.

[github-actions]

Codex AI review

[P2] Defer conversion until the map is read. This executes at both invocation hooks whenever any plugin is registered, so existing plugins that never access the new fields still allocate every OperationInfo and copied error twice per invocation. Large histories can consume substantial Lambda time and memory. Snapshot the raw operation mapping at hook time, then expose a lazy, cached, copy/pickle-safe view that converts entries only on access.

[github-actions]

Codex AI review

One medium-priority performance regression remains. Tests cover map semantics but not operation-heavy executions where plugins ignore these fields.

Reviewed commit 6d51dc7af491b9d03bc599068a282c61aba44c21. Workflow run

[github-actions]

Claude AI review

No actionable findings. The change adds InvocationInfo.operations and InvocationStartInfo.updated_operations to the plugin invocation hooks, and it holds up under review:

• Correctness/determinism: operations_provider=lambda: execution_state.operations reads under lock and returns a fresh copy; ExecutionState.close() (which runs before on_invocation_end) stops/joins but never clears the operation map, so the end-hook re-read correctly reports end-of-invocation state and the start snapshot correctly pins start state. These are observability-only signals, so re-reading at end is safe with respect to replay semantics.
• Isolation: _copy_error clones only the mutable stack_trace list (other ErrorObject fields are immutable), preventing a plugin from altering the error later raised to user code. OperationInfo is frozen, so map entries are otherwise safe to share.
• API compatibility: the new fields are kw-only with empty-dict defaults and repr=False, compare=False, hash=False, so equality/hash/repr of existing infos are unchanged and no operation payloads leak into instrumentation that logs infos wholesale (verified against the OTel invocation plugin and the example plugin). New hook parameters are keyword-defaulted and the sole core caller was updated.
• Gating/error handling: _snapshot_operation_infos returns {} when there are no plugins or no provider and swallows provider exceptions with a logged empty-map fallback, so the plugin-facing view can never break an execution.
• Tests: unit + e2e coverage is thorough (subset semantics, missing-id skip, plugin-free path, provider release, snapshot pinning, dict/pickle/asdict/deepcopy serializability, error-mutation isolation, suspend/replay via UpdatedOperationIds).

Residual test risk: (1) the PR description and the TestInvocationInfoCopySafety docstrings describe a "lazy view / __deepcopy__" design, but the shipped code builds the map eagerly via _to_operation_info_map and stores a plain dict; code and tests are self-consistent (eager), so this is only stale prose, not a defect — worth cleaning up to avoid confusing future maintainers. (2) The author notes an acknowledged pre-existing conformance flake (10-22, PluginOperationChangeShape) and that end-to-end conformance re-verification depends on handlers living in a separate PR, so the live suite has not been re-run against this rebased branch.

Reviewed commit 6d51dc7af491b9d03bc599068a282c61aba44c21. Workflow run