fix(sns): store generic nervous system function call reply on the proposal

[Rachit2323]

What was wrong: when the SNS asks another canister to do something, that canister sends back an answer. But we were never actually reading that answer, we just checked "did it respond at all" and then threw the answer away. So even if the answer said "this didn't work," we'd still mark it as a success, and nobody could ever go back and see what really happened, because we deleted it.

What we fixed: we stopped deleting the answer. Now we save it, so anyone can look at it later and see exactly what came back.

What we did NOT fix: we still can't automatically tell if the answer means success or failure, because this feature can talk to any canister, and every one of them answers differently. There's no way to understand all of them automatically. So we're not trying to guess anymore, we're just making sure the answer doesn't disappear.

Small limit: if the answer is really long, we only keep part of it, so it doesn't take up too much space.

Testing: added tests to check the answer gets saved properly, that nothing changed for the failure case, and that long answers get shortened correctly.

[github-actions]

Run on 828c110 URL: https://github.com/dfinity/ic/actions/runs/33880515408

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to ac0a37f.

Security Overview

• 🔎 Scanned files: 13 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f975f1a5-0a47-4a3b-b7f0-a55609e90390?scanId=4d6b28f3-c4ad-4eb2-8955-75859edc7586&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► rs/sns/governance/api/src/ic_sns_governance.pb.v1.rs       Add execution_reply field to ProposalData ► rs/sns/governance/canister/governance.did       Introduce execution_reply as optional blob in ProposalData ► rs/sns/governance/proto/ic_sns_governance/pb/v1/governance.proto       Add optional bytes execution_reply field to ProposalData
Enhancement	► rs/sns/governance/src/canister_control.rs       Return raw reply bytes from execute_generic_nervous_system_function_call ► rs/sns/governance/src/governance.rs       Store execution reply on proposal after function call via set_proposal_execution_reply ► rs/sns/governance/src/governance/execute_generic_nervous_system_function_tests.rs       Add tests for execution reply handling
Enhancement	► rs/sns/governance/src/gen/ic_sns_governance.pb.v1.rs       Add execution_reply field to ProposalData (protobuf)
Enhancement	► rs/sns/governance/src/governance/test_helpers.rs       Add execute_proposal helper for running proposals and capturing state
Enhancement	► rs/sns/governance/src/pb/conversions.rs       Propagate execution_reply in conversions between proto and API structs
Enhancement	► rs/sns/governance/src/proposal.rs       Update ProposalData serialization/deserialization to include execution_reply field
Enhancement	► rs/sns/governance/unreleased_changelog.md       Document storing of raw execution reply bytes on proposals

[claude]

Re: the governance checklist —

1. Changelog: unreleased_changelog.md is already updated in this PR (entry under ## Fixed describing that generic-function execution replies are now stored on the proposal instead of discarded).
2. Breaking changes: None — this only adds a new optional field (execution_reply) to ProposalData; existing callers and behavior are unaffected.
3. Data migration: Not needed — the new field is optional and simply absent on existing/older proposals.
4. Security review: An automated scan (zeropath-ai) found no issues on the current head, and the PR already carries the security-review-passed label.

@dfinity/governance-team — flagging for a look since this checklist review is what's currently blocking merge (mergeable_state: blocked); CI is otherwise green and no other reviews are outstanding.

---

Generated by Claude Code

[github-actions]

Run on ac0a37f URL: https://github.com/dfinity/ic/actions/runs/34059170845