refactor: add RoutingTable::unassign_canister

[mraszyk]

This PR adds a new public function RoutingTable::unassign_canister removing a canister from the routing table.

The motivation for adding this function is ability (in a follow-up PR) to implement canister migration to a deleted subnet by only removing the canister from the source subnet (using the new function RoutingTable::unassign_canister) without adding the canister to the deleted (target) subnet. This flow would be used if the target subnet is permanently stuck, preventing the canister migration from completing, and if the stuck subnet is then deleted.

[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

No canister behavior changes.

[zeropath-ai]

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

Security Overview

• 🔎 Scanned files: 1 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f975f1a5-0a47-4a3b-b7f0-a55609e90390?scanId=b068d1c2-0a62-47cb-933d-4e09ada0507f&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Refactor	► lib.rs     Introduce unassign_canister and unassign_range functions     Modify assign_canister to call unassign_canister     Modify assign_range to call unassign_range

[Copilot]

Pull request overview

This PR introduces a new public API on RoutingTable to remove an individual canister assignment, enabling follow-up work where canister migration can be “undone” from the source subnet without reassigning to a (potentially deleted/stuck) target subnet.

Changes:

• Refactors single-canister assignment to reuse a new unassign_canister step before inserting the singleton range.
• Adds RoutingTable::unassign_canister (public) and factors out internal unassign_range logic to remove assignments for a canister ID range.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.