fix: subnet deletion in PocketIC with registry canister

[mraszyk]

This PR fixes subnet deletion in PocketIC with registry canister: the issue was that subnet deletion in PocketIC did not sync the local registry into the registry canister.

[Copilot]

Pull request overview

This PR fixes a PocketIC subnet deletion regression when the registry ICP feature is enabled by ensuring local registry changes are also applied to the registry canister, and by correctly exporting tombstone (deletion) records as delete mutations.

Changes:

• Export registry tombstones (value == None) as delete mutations instead of upsert with an empty value.
• Add sync_registry_to_canister to apply pending local registry mutations to the registry canister, and call it during initial registry setup and after subnet deletion.
• Strengthen the subnet-deletion test to run with an NNS subnet + registry feature enabled and to avoid deleting the subnet containing the default effective canister ID.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
rs/registry/proto_data_provider/src/lib.rs	Emit delete mutations for tombstones so registry canister invariants aren’t violated by empty-value upserts.
rs/pocket_ic_server/src/pocket_ic.rs	Keep registry canister and local registry provider in sync (initial upload + post-subnet-deletion).
packages/pocket-ic/tests/tests.rs	Regression test covering subnet deletion with registry feature enabled to prevent sync loops.

---

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

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