Convert British spellings to American across the repo

colour -> color, behaviour -> behavior, centre -> center, favourite ->
favorite, and about twenty other pairs, applied consistently across
comments, docs, error/UI copy, and a handful of QML identifiers that
used the British spelling as their actual name: SystemSettings'
serialiseValue/serialiseTable/normaliseGradient, Displays'
normaliseModes, Wallpaper's normalisePolicy, SettingsBackup's
serialiseHomeState, DateTime's ntpSynchronised property, Clipboard's
_normalise helper, and ShortcutCapture's cancelled signal (with its
onCancelled handler in ShortcutsPage.qml). Every call site and the two
tests that assert on the literal source text (settings-ownership and
settings-backup-live contracts) were updated in lockstep.

Left untouched: config/dot/espanso/match/packages/misspell-en/ is a
vendored third-party autocorrect dictionary -- its entries are typo
corrections, not our prose, and rewriting them would fight the
package's own purpose (and any future re-sync from upstream).

The already-American `favorites` property (Home page pinned
accessories) was never actually misspelled -- only nearby comments and
error strings said "favourites" -- so no data migration was needed
there.

Claude-Session: https://claude.ai/code/session_01E6TJUAh41HaP25MVHWkhRZ

setup/scripts/link-dotfiles

@@ -77,7 +77,7 @@ for dir in "${dirs[@]}"; do
 done
 
 # tmux.conf ends with a source-file of current-theme.conf, generated from the
-# colour scheme rather than committed. Seed it so a fresh checkout starts themed
+# color scheme rather than committed. Seed it so a fresh checkout starts themed
 # -- the source-file is -q, so a missing file is silent, which would leave tmux
 # unstyled with nothing to explain it.
 TMUX_THEME="$PANAMA_DOT/tmux/current-theme.conf"
@@ -95,9 +95,9 @@ elif [ -d "$PANAMA_DOT/tmux/themes" ]; then
   log "Seeded tmux $tmux_scheme theme ($tmux_name) → $TMUX_THEME"
 fi
 
-# hyprlock.conf is generated from a template on every colour scheme change and
+# hyprlock.conf is generated from a template on every color scheme change and
 # is not committed. Seed it so the FIRST lock of a fresh install is themed --
-# without it hyprlock falls back to its own defaults, which is a bare grey
+# without it hyprlock falls back to its own defaults, which is a bare gray
 # screen with none of this desktop's identity, and the first time anyone would
 # find out is when they walked away from the machine.
 HYPRLOCK_TEMPLATE="$PANAMA_DOT/hypr/hyprlock.conf.template"
@@ -176,9 +176,9 @@ for gtk_version in 3.0 4.0; do
 done
 
 # kitty.conf ends with `include current-theme.conf`, and that file is generated
-# from the desktop colour scheme rather than committed -- it is machine state.
+# from the desktop color scheme rather than committed -- it is machine state.
 # A fresh checkout therefore has no such file, and kitty starts by complaining
-# about a missing include and falling back to its stock colours. Seed it from
+# about a missing include and falling back to its stock colors. Seed it from
 # the scheme in settings.json (dark unless the user has chosen otherwise) so a
 # first launch is themed; ColorScheme.qml overwrites it on every change after.
 KITTY_THEME="$PANAMA_DOT/kitty/current-theme.conf"
@@ -226,7 +226,7 @@ done
 # the repository and expose it with a narrow per-file symlink.
 # Panama ships its own application icons. Without these the desktop entries fall
 # back to a generic symbolic glyph, which is drawn for 16px toolbar use and
-# looks wrong beside full-colour application icons in the dock.
+# looks wrong beside full-color application icons in the dock.
 PANAMA_ICON_DIR="$PANAMA_PATH/config/local/share/icons/hicolor/scalable/apps"
 USER_ICON_DIR="$HOME/.local/share/icons/hicolor/scalable/apps"
 mkdir -p "$USER_ICON_DIR"