Make OpenStation settings easier to understand

[nickhamze]

Why this change

We reviewed every setting surfaced by the Settings Clarity run and found a recurring problem: the controls often say what they change, but not who the change affects, when it takes effect, what else it changes, or how to reverse it.

That makes ordinary choices feel riskier than they should. A person should not need to inspect the code—or learn by surprise—that a preference follows their WordPress account, a theme changes other preferences the first time it is selected, a native-window choice applies only when the app is opened again, or a reset reaches every Preferences tab.

The audit covered 137 settings. Of those, 129 are real OpenStation product settings and 8 are deliberately planted test-lab canaries. The canaries remain in the lab; this PR updates the product language only.

What changes

This pass focuses on the shared language problems that made otherwise straightforward settings hard to predict:

• Account and site scope are stated plainly. Appearance and shortcut choices now say they are saved to the current WordPress account. Site-wide options say “for everyone.” Theme uploads say they install a theme for the whole site.
• Timing is honest. Native Posts, Pages, Users, Plugins, and Comments choices now say they apply the next time the app opens and do not replace a window that is already open.
• Reset is no longer vague. “Reset to defaults” becomes “Reset all OpenStation preferences,” with an explanation that it reaches every Preferences tab, clears the saved custom-wallpaper choice, keeps the Media Library file, and cannot be undone.
• Theme side effects are disclosed. The Themes tab explains that the first selection applies the theme’s recommended preferences. The reapply action no longer promises “layout and effects” when a theme may recommend a different set of preferences.
• Shortcut placement is easier to understand. “On both” and “Hidden” become “Desktop and dock” and “Nowhere,” and each picker is named for the shortcut it controls.
• File Associations describe the actual decision. Every row now reads “Default app for …,” including the accessible control name, and explains that the choice belongs to the account and is used the next time a file opens.
• Mio’s abstract controls use visible outcomes. “Hue spread,” “Iridescence,” “Spin the gradient,” and “Restore Mio” become “Colour range,” “Holographic strength,” “Move gradient around ring,” and “Reset Mio’s look.” Zero-value controls say when zero means off.
• Shared Posts and Pages column choices are disclosed. The menu identifies whether it belongs to Posts or Pages, while Author and Date say they are shared by both.

Representative examples:

Before	After	Why
“saved to this browser”	“saved to your WordPress account”	The preference follows the signed-in user across browsers.
“Reset to defaults”	“Reset all OpenStation preferences”	The action reaches far beyond the visible Appearance tab.
“Use the native Posts window”	“Open Posts in the native window”	This is a routing choice used on the next open, not a live conversion of the current window.
“Apply recommended layout and effects”	“Apply recommended preferences”	Themes can recommend keys outside those two categories.
“Show in”	“Where to show [app]”	Each repeated picker now has a clear, distinct question.

What this PR does not claim to fix

This is intentionally a language-focused PR. The audit also found behavior bugs—failed-save rollback, rapid-toggle races, Spatial-layout placement, live opener refresh, ribbons that remain visible, and similar problems. Those need code fixes and are being tracked separately. The copy here does not disguise or close them.

The 16 findings from the audit

Every finding has its own destination now, so this PR does not become a catch-all bug report.

This PR fully resolves the wording or accessible-name problem in:

• Closes Appearance says preferences stay in one browser, but they follow the account #584
• Closes The theme recommendation button promises the wrong changes #587
• Closes Native-window choices do not explain that they apply on the next open #589
• Closes The Features introduction promises behavior its controls do not share #590
• Closes File Association dropdowns are unnamed for screen readers #591
• Closes Posts and Pages silently share the Author and Date column choices #596

It improves the explanation, while leaving the remaining interaction decision open, in:

• Choosing a theme for the first time silently changes other preferences #582 — preview or confirm the extra preferences applied on first theme selection
• Reset all preferences needs a confirmation and a way back #583 — add confirmation and recovery to the full-preferences reset

The behavior bugs remain separate:

• A quick second change in Extended Options saves the wrong value #552 — rapid Extended Options changes save the wrong value
• A failed shortcut save leaves the desktop and dock out of sync #585 — failed shortcut saves leave the desktop and dock out of sync
• Spatial layout ignores Apps & Icons placement choices #586 — Spatial layout ignores shortcut placement choices
• New file openers do not appear until Preferences is reopened #588 — late file openers do not refresh the mounted Preferences tab
• Mio can look holographic while Use holographic effect is turned off #592 — Mio's holographic checkbox and strength control can disagree
• A failed column save leaves Posts and Pages showing the rejected layout #593 — failed Posts/Pages column saves leave stale UI
• Mio can wobble while Use idle wobble is turned off #594 — Mio's idle-wobble checkbox and strength control can disagree
• Post-status ribbons stay visible after the setting is turned off #595 — post-status ribbons remain after the setting is off

Checks run

• npm run lint
• npm run typecheck
• npm run test:js — 4,260 tests passed
• npm run build