fix: back up the stylesheet next to it, and don't copy read-only permissions

[mattchristenson]

Fixes #266.

Problem. After each Forge update (setting css-last-update differs from Forge's own tag), patchCss() backs up the user's stylesheet (~/.config/forge/stylesheet/forge/stylesheet.css) and copies the default stylesheet over it. That had two bugs, both reported in #266:

• Backup location. The backup's name came from this.configMgr.stylesheetFileName, a property that doesn't exist. So the backup was written to undefined.bak in GNOME Shell's working directory, which is usually the home folder.
• Permissions. Gio.File.copy() gives the copy its source's permissions unless it is passed TARGET_DEFAULT_PERMS. Where the extension's files are read-only (NixOS, as in the report, or a package that installs them 0444), the user's stylesheet and the backup became read-only too. At the next update, copying over them failed with "Permission denied", enable() threw, and Forge didn't start until both files were chmoded.

Change.

• The backup is stylesheet.css.bak, next to the stylesheet.
• Both copies use TARGET_DEFAULT_PERMS, so they get the usual permissions of a new file.
• A read-only copy left by an earlier version is replaced: when the copy fails with PERMISSION_DENIED and the target exists and isn't writable, the target is deleted and copied again. An unreadable source never deletes anything.
• If the update still fails, Forge says why with console.warn and starts with the stylesheet it has. It tries again at the next start.

A ~/undefined.bak left by earlier versions stays where it is; it can be deleted.

Testing. Scenario scenarios/31_stylesheet_update_backup.py. It uses the sandbox's own directories, and makes the sandbox's copy of Forge read-only, as such an install is:

• 31.1: after an update, the backup is stylesheet.css.bak next to the stylesheet, and no undefined.bak is written to GNOME Shell's working directory;
• 31.2: the updated stylesheet and its backup can be written by the user;
• 31.3: after a second update Forge starts, and the update went through;
• 31.4: with a read-only stylesheet and backup left by an earlier Forge, an update works again.

On main, the permission error from the issue stops Forge:

  FAIL  31.1 update: Forge ACTIVE; backup stylesheet.css.bak: False; undefined.bak in GNOME Shell's working directory: True
  FAIL  31.2 the stylesheet and its backup can be written: False, False
  FAIL  31.3 a second update: Forge ERROR: Gio.IOErrorEnum: Error opening file “…/forge/stylesheet/forge/stylesheet.css”: Permission denied; css-last-update 1 (expected 37)
  FAIL  31.4 read-only stylesheet and backup from before: Forge ERROR: Gio.IOErrorEnum: Error opening file “…/forge/stylesheet/forge/stylesheet.css”: Permission denied; css-last-update 1 (expected 37)

With this PR:

  PASS  31.1 update: Forge ACTIVE; backup stylesheet.css.bak: True; undefined.bak in GNOME Shell's working directory: False
  PASS  31.2 the stylesheet and its backup can be written: True, True
  PASS  31.3 a second update: Forge ACTIVE; css-last-update 37 (expected 37); stylesheet replaced by the new default: True
  PASS  31.4 read-only stylesheet and backup from before: Forge ACTIVE; css-last-update 37 (expected 37); stylesheet replaced by the new default: True

main 0/4 → 4/4. The rest of the suite (scenarios 01–30) gives the same results as on main, apart from checks whose results vary between runs on main itself (3.4, a key-repeat resize; 23.1, #268). prettier@2.7.1 --check is clean.

🤖 Generated with Claude Code