Ship the packagekit block hook on desktop editions, not only Handheld

I had help with Claude/AI on this, but thought it was worth reporting.

CachyOS blocks `packagekit` in two places — the Handheld edition's `blocked-packages.hook`, and the Live ISO installer ("Blocked packagekit installation to prevent issues with system updates via Discover") — and the wiki FAQ warns about it in roughly ten languages.

None of that applies to a desktop install. On mine there is no `blocked-packages.hook` under `/usr/share/libalpm/hooks/` or `/etc/pacman.d/hooks/`, and this ran without any warning:

```
[2026-08-10T22:26:32+1000] [PACMAN] Running 'pacman -S flatpak discover packagekit-qt6'
[2026-08-10T22:26:49+1000] [ALPM] installed discover (6.7.4-1.1)
[2026-08-10T22:26:49+1000] [ALPM] installed packagekit (1.3.6-1.1)
```

Installing Discover and wanting it to manage repo packages is a normal thing for a KDE user to do, and nothing on a desktop install pushes back.

## Why this is worth blocking rather than only documenting

I hit the failure and traced it. On a `v3`/`v4` package set PackageKit's alpm backend does not merely misbehave occasionally — it cannot complete an update at all, and it fails destructively:

1. `pk-alpm-config.c` reimplements `Architecture = auto` as bare `uname()` (`x86_64`) and then calls `alpm_option_set_architectures()`, overriding libalpm's own detection — including CachyOS's `x86_64_v4` support.
2. Every installed package therefore fails `check_arch()`, and `alpm_trans_prepare()` returns `ALPM_ERR_PKG_INVALID_ARCH`.
3. PackageKit then segfaults building the error message, because it treats that error's `char *` data list as `alpm_pkg_t *`.
4. The respawned daemon aborts on an assertion placed *before* `alpm_trans_release()`, so `/var/lib/pacman/db.lck` is leaked every time.

Step 4 is the part that bites: with a stale lock and no process holding it, every subsequent operation — pacman, paru, octopi, anything — fails until the file is removed by hand, and nothing anywhere says "lock". In my case two days passed before I worked out the system simply could not be updated by any tool.

Filed upstream with the full analysis: https://github.com/PackageKit/PackageKit/issues/1009

Note this is specific to the optimised repos. A CachyOS user on plain `x86_64` never reaches it, because `uname` matches their packages. So it affects precisely the users the v3/v4 repos are aimed at.

## Suggestion

Ship the existing Handheld hook from this package so desktop installs get it too — the file already exists and needs no changes:

```
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = packagekit

[Action]
Description = "The transaction is attempting to install packagekit. Packagekit is broken on arch and should not be used. Transaction cancelled."
When = PreTransaction
Exec = /usr/bin/false
AbortOnFail
```

Blocking `packagekit` does not cost Discover anything users actually want on CachyOS: its Flatpak and fwupd backends are independent of PackageKit, so Discover keeps working for Flatpaks and firmware, which is what the wiki already recommends limiting it to.

If a hard block on desktop feels too blunt — it would also stop anyone deliberately installing it — a `PreTransaction` warning that does not abort would still be a large improvement over silence.

Locate the existing Handheld blocked-packages.hook in the package sources and check how edition-specific files are included. Ensure the built desktop package ships that hook, then verify that a packagekit installation transaction is blocked on a desktop edition.

Written by the indexing model from the issue text.