fix: disconnect signals before destroying objects in disable()

## Bug

When the extension is disabled (e.g. during automatic suspend), \`disable()\`
destroys \`_indicator\` and \`_keybindings\` before calling \`_signals.disconnect()\`.
Both objects have signal handlers registered via \`_signals\`, so disconnecting
after destroying them causes a GObject assertion failure:

\`\`\`
Object Indicator (0x55993d6d0950), has been already disposed — impossible
to access it.
== Stack trace for context 0x55993bd19f70 ==
#0 resource:///org/gnome/gjs/modules/core/overrides/GObject.js:710
#1 tilingshell@ferrarodomenico.com/utils/signalHandling.js:17
#2 self-hosted:157
#3 tilingshell@ferrarodomenico.com/utils/signalHandling.js:16
#4 tilingshell@ferrarodomenico.com/extension.js:573
#5 resource:///org/gnome/shell/ui/extensionSystem.js:217
\`\`\`

This leaves GNOME Shell in a partially torn-down state, which can cascade into
dash-to-dock and other extensions having corrupted actor trees, ultimately
deadlocking the Wayland compositor when gsd-power attempts to coordinate a
suspend.

## Fix

Move \`_signals?.disconnect()\` / \`_signals = null\` to the top of \`disable()\`,
before any \`destroy()\` calls. I have a fix ready as a PR.

## Environment

- Fedora, GNOME 49.6
- tilingshell 17.3

Start at disable() around extension.js:573 and inspect the signal cleanup in utils/signalHandling.js. Verify that signal disconnection occurs before the Indicator and keybindings objects are destroyed, then reproduce or check the reported GObject assertion during disable().

Written by the indexing model from the issue text.