Refactor Settings shell into focused frontend modules

[alteixeira20]

Prerequisites

• I searched open issues and this has not already been proposed.
• I searched discussions and this is not already being debated there.
• This is a concrete, actionable proposal.

Area

UI / Frontend

Problem or Motivation

static/js/settings.js currently owns several unrelated Settings-window
responsibilities in one large module, including panel activation, modal
dragging and docking cleanup, close/Escape handling, and modal visibility
lifecycle.

Keeping those responsibilities embedded in the monolith makes subsequent
Settings maintenance harder to review and makes it easier to duplicate
window-shell behavior.

This proposal is deliberately narrow. It does not redesign Settings and does
not introduce a new frontend framework.

Proposed Solution

Extract the existing Settings shell into focused ES modules:

• static/js/settings/dom.js — shared DOM lookup helper
• static/js/settings/navigation.js — tab/panel activation and admin-tab delegation
• static/js/settings/lifecycle.js — dragging, dock reset, close/Escape behavior,
  show/hide lifecycle, and the delegated Persona-editor handoff

Then wire static/js/settings.js through those modules and remove its duplicate
shell implementations.

Existing behavior must remain unchanged, including:

• Appearance/Peek behavior
• AI-tab endpoint refresh
• admin-tab delegation
• nested integration-form Escape handling
• drag/dock reset
• backdrop/X/Escape close behavior
• direct Settings open/close calls

Add focused behavioral coverage that executes the production shell modules.

Alternatives Considered

Keeping the logic inside settings.js avoids immediate movement but leaves
unrelated lifecycle/navigation concerns coupled to panel implementations.

A complete Settings or frontend rewrite would address the same maintainability
problem at much greater scope and review cost.

A generic component abstraction is also unnecessary here; the existing
ES-module structure is sufficient for this behavior-preserving extraction.

Prior Art / Related Issues

Related in motivation to broader frontend architecture work, but intentionally
implemented as a small standalone refactor of the current frontend rather than
a framework migration.

Are you willing to implement this?

Yes — I can open a PR