fixing some issues with remote modules

[mohitulm]

Currently, in remote rpyc server-client setup, the client breaks when the server shuts down. Also the client should not be able to control deactivation of the remote server modules. The PR introduces changes to address these issues.

Description

Three related fixes for remote (rpyc) module robustness:

1. Fix TypeError on deactivation of remote modules with _threaded = True.
   On the client, self._instance is an rpyc netref, not a QObject. PySide's
   stricter type check on QMetaObject.invokeMethod rejects it. The threaded
   code path also doesn't make sense for remote modules — their thread lives on
   the server. activate now skips the threaded branch when self.is_remote;
   deactivate skips it via the new local-only path (item 3 below).

   Reproduces with any scanner_gui toolchain, because ScanningProbeDummyBare
   is the only dummy module that sets _threaded = True.

2. Survive remote server shutdown. Previously, an EOFError/OSError from
   a dead rpyc connection propagated out of state, is_active, is_busy,
   _disconnect, and _disable_state_updated, wedging the client.

   • state returns 'DISCONNECTED' (socket errors) or 'BROKEN' (other
     errors) for remote modules instead of raising. Local modules re-raise as
     before. Removes the previous bare except: that also swallowed
     KeyboardInterrupt.
   • is_active/is_busy route through state and return False safely.
   • _disconnect and _disable_state_updated tolerate dead connections and
     Qt's already-deleted-object errors so cleanup runs to completion.
   • activate auto-reloads a remote module that's in 'BROKEN' or
     'DISCONNECTED' state.
   • _poll_module_state logs an error once per disconnect event.

3. Don't drive server-side deactivation from the client. Previously,
   deactivate() on a remote module called module_state.deactivate() and
   disconnect_modules() over rpyc, tearing down server-side FSM and
   connector state. Now remote deactivate() only cleans up locally: stops
   the poll timer, drops the proxy, emits signals. The server's module is
   left untouched. Re-activating on the client fetches a fresh proxy.

Backward compatibility

• 'DISCONNECTED' and 'BROKEN' are new state strings, only emitted for
  remote modules under the failure conditions above.
• Deactivating a remote module from the client no longer transitions the
  server-side FSM. Users who relied on this should deactivate from the
  server side instead.

How Has This Been Tested?

Tested with a remote server and client config for some modules.

• Loading scanner_gui and quitting via Ctrl+C: previously crashed with
  TypeError; now exits cleanly.
• Killing the server while the client runs: previously wedged the client;
  now logs the disconnect, marks modules as 'DISCONNECTED', and stays
  usable.
• Restarting the server and re-activating from the manager GUI reconnects
  without having to restart the client.
• Deactivating a remote module on the client no longer affects the
  server's module state.

Types of changes

• Bug fix
• New feature
• Breaking change (Causes existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• I have documented my changes in /docs/changelog.md.
• My change requires additional/updated documentation.
• I have updated the documentation accordingly.
• I have added/updated the config example for any module docstrings as necessary.
• I have checked that the change does not contain obvious errors
  (syntax, indentation, mutable default values, etc.).
• I have tested my changes using 'Load all modules' on the default dummy configuration.
• All changed Jupyter notebooks have been stripped of their output cells.