fix: disconnect FeatureIndicator settings handler + correct theme cleanup

[mayconrcmello]

Summary

Two small lifecycle fixes that surface during repeated enable/disable cycles (a common path during development, plus user-triggered prefs reloads or extension scans).

1. FeatureIndicator leaks a settings signal handler

indicator.js connects to extension.settings.connect("changed", …) in the constructor without storing the handler id. Gio.Settings returned by getSettings() is cached for the lifetime of the gnome-shell process, so the handler outlives the indicator. Every enable/disable cycle adds another listener; toggling tiling-mode-enabled or quick-settings-enabled then fires N callbacks, each operating on a previous (destroyed) indicator object.

Fix: store the id, override destroy() to disconnect.

2. extension.js disable() typo: themeWm instead of theme

enable() assigns this.theme = new ExtensionThemeManager(this), but disable() was clearing this.themeWm = null — a no-op that left this.theme referencing the manager after disable. Replaced with this.theme = null and added a comment explaining the previous typo.

Test plan

• node --check on both touched files.
• Manual reload cycles via gnome-extensions disable forge@jmmaranan.com && gnome-extensions enable forge@jmmaranan.com repeated several times — no journal warnings about tiling-mode-enabled callbacks firing on destroyed objects.
• Toggle Super+T after multiple reloads — only one settings listener active.

Notes

• Both changes are zero-behaviour for the happy path; they only affect state cleanup at disable time.
• The settings leak compounds over time, so it can hide other extension bugs by spraying spurious GC sweep warnings into the journal.