Fix floating window profile persistence and treat appearance/position/layer as global settings

[Programmer-MrWang]

Motivation

• Make floating-window profiles responsible only for button layout and button/row rulesets and avoid leaking shared appearance/position/layer into per-profile JSON.
• Ensure triggers registered while the editor is closed or on fresh/migrated installs are still shown until explicitly configured.
• Persist edits made in the ruleset editor drawer to the correct owner (profile vs main config) so changes survive restart.

Description

• Remove appearance/position/layer fields from FloatingWindowProfile and stop migrating them into profile JSON in FloatingWindowProfileManager.MigrateFromLegacyConfig() so profiles only contain button layout and rulesets.
• Read appearance, scale, opacity, shadow, drag-handle and layer settings from MainConfigData (_configHandler.Data) when rendering/updating the floating window and when saving window position or layer changes in FloatingWindowService (e.g., EnsureWindow, RefreshWindowButtons, EnsureWindowPositionVisibleOnStartup, SavePosition, RecheckWindowLayer, SetWindowLayer, ToggleWindowLayer, RefreshLayerRecheckMode).
• Keep the previous fallback behavior for unconfigured triggers by adding GetConfiguredButtonRowsWithFallback() and using it in row rendering and visibility checks so new/unconfigured buttons are appended (and profile is saved where appropriate).
• Persist edits from the ruleset drawer: add SaveCurrentRulesetTarget() in FloatingWindowEditorSettingsPage.axaml.cs and call it from ruleset property/collection change handlers and drawer toggles so button/row ruleset edits save the profile and window ruleset edits save MainConfig.
• Update settings bindings in the editor UI (FloatingWindowEditorSettingsPage.axaml) to bind shared appearance/layer controls to ViewModel.Settings (global MainConfigData) instead of the per-profile object.
• Adjust action ToggleFloatingWindowLayerAction to snapshot and read layer state from the global MainConfigData instead of the profile.

Testing

• Ran git diff --check with no whitespace errors. (passed)
• Attempted dotnet build but the runtime is not available in the environment so a full build/test could not be executed (dotnet: command not found). (not run)
• Verified local source edits and diffs for the following files: ConfigHandlers/FloatingWindowProfile.cs, ConfigHandlers/FloatingWindowProfileManager.cs, Services/FloatingWindowService.cs, SettingsPage/FloatingWindowEditorSettingsPage.axaml, SettingsPage/FloatingWindowEditorSettingsPage.axaml.cs, and Actions/ToggleFloatingWindowLayerAction.cs.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f6ddf114b7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Migrate existing profile appearance settings

For users upgrading from a build that already wrote floating-window profile JSON, appearance and layer edits were saved only on FloatingWindowProfile via the old editor bindings; MigrateFromLegacyConfig() now returns as soon as Default.json exists and never copies those existing profile values back into MainConfigData. With these lines now rendering from _configHandler.Data, those users silently fall back to stale/default global scale/icon/text/opacity (and similarly layer/drag-handle settings) and the next profile save drops the old JSON fields, so their persisted settings are lost unless a one-time migration/backfill reads the current profile's old fields first.

Useful? React with 👍 / 👎.