fix(plugin): make payload fields additive on hook infos

[wangyb-A]

Follow-up to #616, which merged before these could be pushed to its branch.
Addresses both review comments on #616 (commit d92013f) — both findings
landed on main with the merge, so they are live today.

1. High: payloads leaked into repr (plugin.py:212)

Dataclass fields appear in the generated repr, and instrumentation logs hook
infos wholesale:

• aws-durable-execution-sdk-python-otel logs "Durable invocation started: %s", info
  (and the end hook, and the operation hooks) at debug
• the bundled plugin example logs f"Invocation started: {info}" at info

So merely adding execution_input / execution_result caused customer input
and results — potentially secrets, potentially megabytes — to be written to
logs implicitly, with no plugin asking for it. Reproduced before fixing:

InvocationStartInfo(request_id='r', execution_arn='a', is_first_invocation=True,
                    execution_start_time=None,
                    execution_input={'password': 'hunter2', 'ssn': '123-45-6789'})

Fix: repr=False on both fields. Identity fields (request_id,
execution_arn, timestamps, status) still render, so the repr stays useful.

2. Medium: payloads changed equality and broke hashing (plugin.py:183)

The fields joined the generated __eq__ / __hash__, so the widening was not
additive. Reproduced:

hash(dict input)      : RAISED TypeError: unhashable type: 'dict'
hash(list input)      : RAISED TypeError: unhashable type: 'list'
prior == with-payload : False

execution_input is Any — arbitrary deserialized JSON — so a dict or list
value made a previously hashable InvocationStartInfo unhashable. Both fields
also made infos built from the earlier field set compare unequal to infos
carrying a payload.

Fix: compare=False, hash=False on both. Identity fields still drive
equality, so payload-only differences now compare equal — payloads are
incidental data on what is otherwise an event record.

Testing

• repr: secret-looking values never appear in either hook info's repr, while
  request_id / execution_arn still do.
• hashing: stable across dict, list, nested and scalar payloads, and equal to
  the payload-free hash.
• equality: infos from the prior field set compare equal to payload-carrying
  infos; two different payloads compare equal; identity fields still drive
  inequality.
• Declaration-level tests pinning Field.repr / Field.compare / Field.hash,
  so the intent survives a refactor of the generated methods.
• All five verified to fail when the field arguments are removed.
• 1519 unit tests passing; hatch fmt --check clean.

Worth a maintainer decision (not changed here)

OperationInfo.result / OperationInfo.error from #625 remain in compare and
in repr. They are hashable types, so they do not break hash(), but they
carry operation-level payloads through the same log sites and now differ from
these fields in equality semantics. Aligning them is a small change if you want
consistency.

[github-actions]

Codex AI review

No actionable findings. Static review only; tests were not run per the review constraints.

Reviewed commit 2edac5ab694c65e2c494bb0ca2c2019842287125. Workflow run

[github-actions]

Claude AI review

This PR makes the execution_input / execution_result payload fields additive on the invocation hook infos by adding repr=False, compare=False, hash=False. The change is correct, minimal, and well-tested.

Verified:

• repr=False stops payloads leaking into the generated repr. The wholesale-logging sites the PR cites are real: execution_plugin.py:206/276, invocation_plugin.py:366/409 (debug), and examples/.../execution_with_plugin.py:28/31 (info). Identity fields still render.
• compare=False already excludes each field from __eq__/__hash__; the explicit hash=False is redundant but harmless and matches the declaration-pinning test. Fields inherit correctly into InvocationStartInfo/InvocationEndInfo.
• No regression from widened equality: no consumer uses these infos as dict keys or set members (OperationChangeInfo maps are keyed by operation_id strings), and no OTel/testing/example test asserts whole-object equality or assert_called_once_with on them — existing tests read the attributes directly, which still work.
• The five new tests are well-formed (imports resolve) and cover repr exclusion, declaration pinning, hashability across dict/list/nested/scalar payloads, equality invariance, and identity-driven inequality.

No actionable findings.

Residual risk (unchanged lines, out of scope): InvocationEndInfo.error and OperationInfo.result/error remain in repr and compare, so error/operation payloads still flow through the same wholesale log sites and now differ from these fields in equality semantics. The author already flags this as a maintainer decision; worth aligning in a follow-up.

Reviewed commit 2edac5ab694c65e2c494bb0ca2c2019842287125. Workflow run