fix: Update SnapController state when SnapsRegistry changes

[FrederikBolding]

Trigger registry updating logic in the SnapController every time the SnapsRegistry database changes. Previously we would only do this when updateRegistry was called. This will make it easier to add polling logic to SnapsRegistry and ensures that the SnapController is up to date if the registry is updated by other means.

---

Note

Medium Risk
Adds event-driven registry processing for snap blocking/unblocking and preinstalled updates, which can affect snap availability and update behavior if the new subscription misfires or races with state updates. Changes are localized but touch security-relevant blocklist enforcement paths.

Overview
SnapController now stays in sync with registry changes. It subscribes to SnapsRegistry:stateChange and runs the existing registry-processing logic (block/unblock installed snaps and optionally auto-update preinstalled snaps) whenever the registry database updates.

updateRegistry() is narrowed to only trigger SnapsRegistry:update, with the blocking/unblocking + preinstalled-update work moved into a new private #handleRegistryUpdate() invoked by the registry event (with error logging). Tests and test utilities are updated so MockSnapsRegistry self-registers action handlers on the messenger and emits SnapsRegistry:stateChange on update, and affected tests now construct the registry with the messenger and wait for state propagation where needed.

^{Written by Cursor Bugbot for commit 81b2f56. This will update automatically on new commits. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 98.39%. Comparing base (5ab30ee) to head (81b2f56).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...ages/snaps-controllers/src/snaps/SnapController.ts	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3828      +/-   ##
==========================================
- Coverage   98.40%   98.39%   -0.01%     
==========================================
  Files         430      430              
  Lines       12448    12453       +5     
  Branches     1933     1933              
==========================================
+ Hits        12249    12253       +4     
- Misses        199      200       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Missing subscription cleanup in destroy causes memory leak

Medium Severity

The new SnapsRegistry:stateChange subscription uses an anonymous callback function, and no reference is saved. This makes it impossible to unsubscribe in the destroy() method. Other subscriptions (like ExecutionService:unhandledError) follow a pattern where callbacks are bound and stored as class properties so they can be properly cleaned up. This missing cleanup means the destroyed controller remains referenced by the messenger, causing a memory leak and potentially triggering handlers on destroyed instances.

Additional Locations (1)

• packages/snaps-controllers/src/snaps/SnapController.ts#L3614-L3642