Search Widget: On deactivation, removing more widgets than expected

### Impacted plugin

Jetpack

### Steps to Reproduce

Originally reported in p1642627980029300-slack-CDD9LQRSN

VIP has an automated process that reconnects a site to Jetpack that is disconnected. During the reconnection process, `Jetpack::handle_post_authorization_actions` fires.

As part of that, modules are deactivated/reactivated.

Within Search, both classic and instant search fires `add_action( 'jetpack_deactivate_module_search', array( $this, 'move_search_widgets_to_inactive' ) );`

That function's intent is to move the Search widgets to the inactive widgets section. VIP is reporting that, at least in the case of one client site, it is disabling whole sidebar's worth of widgets.

### A clear and concise description of what you expected to happen.

Question 1: Do we actually need this function? Could we leave the widget there, not output on the front-end and have a note on the backend that this widget can be removed or needs Search enabled?

2. If we do need this function, we should figure out what's happening to cause such a delta. Notice the old vs new widgets in an example request 2b66a-pb/#js

### What actually happened

_No response_

### Other information

_No response_

### Operating System

_No response_

### OS Version

_No response_

### Browser

Other / Not applicable

### Browser Version(s)

_No response_

Start by tracing Jetpack::handle_post_authorization_actions and the Search deactivation hook that calls move_search_widgets_to_inactive for both classic and instant search. Compare the old and new widgets in the referenced example request to determine why unrelated sidebar widgets are moved. Done means establishing the intended deactivation behavior and preventing excess widgets from being disabled.

Written by the indexing model from the issue text.