fix(sns-wasm): actually overwrite existing SNS-specific upgrade path entries

[Rachit2323]

Problem

insert_sns_specific_upgrade_path_entry is used to set a one-off emergency upgrade step for a specific SNS (e.g. "if this SNS is stuck at version A, send it to version B instead"). If you try to change that step later (e.g. because B turned out to be wrong, so it should now go to C), the function only logs that it is "being overwritten" but never actually writes the new value. The old entry stays in place, while the caller is told the request succeeded.

Fix

Actually write the new value when overwriting an existing entry, the same way the sibling function insert_upgrade_path_entry already does a few lines below it.

Testing

Added test_insert_sns_specific_upgrade_path_entry_overwrites_existing_entry, which inserts an entry, overwrites it with a different target, and checks that the second value is the one actually returned. This test fails on the old code and passes with the fix.

[github-actions]

Run on 396e508 URL: https://github.com/dfinity/ic/actions/runs/31978880578

[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 06aec4f.

Security Overview

• 🔎 Scanned files: 2 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f975f1a5-0a47-4a3b-b7f0-a55609e90390?scanId=3f35b6f3-0bca-4223-9c39-d540ba289838&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► rs/nns/sns-wasm/src/sns_wasm.rs     Implement and adjust SNS-specific upgrade path entry overwrite behavior ► rs/nns/sns-wasm/unreleased_changelog.md     Update changelog to document replacement of SNS-specific upgrade path entries

[claude]

@Rachit2323 Since this touches governance-owned code, here are answers to the automated checklist so you can dismiss that review:

1. Changelog — this is an externally-observable behavior fix (via the governance-gated insert_upgrade_path_entries canister method), so a changelog entry is warranted. Suggested addition to rs/nns/sns-wasm/unreleased_changelog.md:

## Fixed

* `insert_upgrade_path_entries` now actually overwrites an existing
  SNS-specific upgrade path entry when called again for the same
  `(sns_governance_canister_id, from_version)` pair, instead of silently
  keeping the old target while reporting success.

2. Breaking? No — behavior of the broken overwrite path now matches the already-correct sibling function; no signature or type changes.
3. Data migration? No — purely an in-memory map-entry fix, no stored-state format change.
4. Security review? Already covered — this PR carries the security-review-passed label and the automated security scan reported no issues.

To clear the bot's review: use the "⋯" menu on its review, choose "Dismiss review", and paste answers to the 4 items (including the changelog snippet above, or your own wording) into the dismissal box.

Generated by Claude Code

[Rachit2323]

1. Changelog: Done. Added a note about this fix.

2. Breaking changes: No. This just fixes a function to actually do what it was already supposed to do. Nothing about how you call it changed.

3. Data migration: No. This only affects what happens the next time someone calls this function - it doesn't touch any existing data.

4. Security review: Not needed. This is a small internal logic fix, no new inputs or permissions involved. The automated security scan (zeropath-ai) already came back clean.

[github-actions]

Run on 573426c URL: https://github.com/dfinity/ic/actions/runs/32017685403

[claude]

@Rachit2323 quick clarification — item 1 needs an actual commit adding that entry to rs/nns/sns-wasm/unreleased_changelog.md; a comment reply alone won't satisfy the bot's check (the PR still only shows the one file changed). Once you push that, use the "⋯" menu on the bot's review to dismiss it with your answers in the box — that's what actually clears mergeable_state.

---

Generated by Claude Code

[claude]

@Rachit2323 thanks for adding the changelog entry — one correction needed: it names the wrong function. The PR fixes insert_sns_specific_upgrade_path_entry, not insert_upgrade_path_entries (a different batch entry-point in the same file). Mind updating the changelog line to reference the right function name?

---

Generated by Claude Code

[github-actions]

Run on //rs/migration_canister:migration_canister_test URL: https://github.com/dfinity/ic/actions/runs/32058856840

[github-actions]

Run on eb54038 URL: https://github.com/dfinity/ic/actions/runs/32059065440

[claude]

@Rachit2323 heads up — master moved (a routine changelog release cut the old entries in unreleased_changelog.md), which now conflicts with this PR. To fix: merge/rebase origin/master into your branch, and in the conflict in unreleased_changelog.md's ## Fixed section, keep the section header and only your new entry (the get_available_sns_subnet one is already released, so master dropped it — no need to bring it back). No code conflict, just that one file.

---

Generated by Claude Code

[github-actions]

Run on 06aec4f URL: https://github.com/dfinity/ic/actions/runs/32110444482