fix: disconnect the settings handlers when Forge is disabled

[mattchristenson]

Fixes #581.

Change.

• WindowManager keeps the id of its settings handler and disconnects it in _removeSignals(), which runs on disable.
• FeatureIndicator keeps its handler id and disconnects it in destroy().
• A window closing as Forge is disabled. A closing window has already left the window list, but its actor keeps Forge's destroy handler and borders until the close animation ends. _removeSignals() only went over the listed windows, so windowDestroy() still ran after disable() and queued a render, which failed with the same error. WindowManager now keeps the actors it connected to in a set and releases all of them.

Testing. Scenario scenarios/29_settings_after_disable.py:

• 29.1: disable Forge, change two of its settings twice each. On main that gives 4 JS errors (this.ext.settings is null); with this PR, none;
• 29.2: enable again: a new window tiles, and changing a setting raises no errors;
• 29.3: close a window and disable Forge when the window leaves the window list, while its close animation runs. On main that gives 1 JS error; with this PR, none.

With this PR:

  PASS  29.1 settings changed while Forge is disabled: new Forge errors 0 (expected 0)
  PASS  29.2 enabled again: a new window tiled: True; new Forge errors 0 (expected 0)
  PASS  29.3 a window closed as Forge is disabled: new Forge errors 0 (expected 0; animations on: True)

main 1/3 → 3/3. The rest of the suite (scenarios 01–28, run again with both commits) gives the same results as on main; the only differences were checks whose results vary between runs on main itself (3.4, a key-repeat resize; 23.1, #268; scenario 07, where VS Code didn't open in time). prettier@2.7.1 --check is clean.

🤖 Generated with Claude Code