chore: bump epoch on moongreet-git and sweet-cursors-git

Local AUR/older builds outsort the registry versions on pacman vercmp:

- sweet-cursors-git: paru-built r445 (Gigas002/Sweet#cursors) > registry
  r1 (our snapshot fork). Snapshot stays frozen by design.
- moongreet-git: pre-rollback 0.10.0 > current 0.8.6 (upstream tag
  history continued at 0.8.4–0.8.6 on top of an earlier 0.10.0 line).

epoch=1 on both, pkgrel bumped to retrigger CI. Also extends .gitignore
to cover the remaining makepkg bare-clone dirs (moongreet, moonlock,
moonset, sshfs_connect) that weren't listed before.

DECISIONS.md

@@ -1,5 +1,17 @@
 # Decisions
 
+## 2026-04-28 – Bump epoch on moongreet-git after upstream version rollback
+- **Who**: Dominik, ClaudeCode
+- **Why**: `pacman -Syu` warned that local `moongreet-git 0.10.0.r0.gce9f219-3` is "newer" than the moonarch registry's `0.8.6.r0.gb9b6f50-1`. Cause: `greetd-moongreet` upstream was tagged `v0.9.0` and `v0.10.0` early on, then the tag history continued with `v0.8.4` → `v0.8.5` → `v0.8.6` patches on top — a deliberate downgrade of the version line. `pkgver()` uses `git describe --long --tags`, which now returns `0.8.6.r0.gb9b6f50` at HEAD, but any system that built moongreet before the tag rollback still has the higher-sorting `0.10.0` installed. Without an epoch bump, those systems will never accept the registry's 0.8.x as an upgrade.
+- **Tradeoffs**: Re-tagging upstream to leapfrog past v0.10.0 (e.g. v0.11.0) would also resolve the mismatch and avoid the epoch — but it would create a fake version that doesn't reflect the actual feature scope, and we'd be permanently chasing the v0.10.0 ghost on every future bump. Epoch is the canonical pacman mechanism for exactly this situation; one-time cost, no upstream lie.
+- **How**: `epoch=1` added to `moongreet-git/PKGBUILD`, `pkgrel` bumped 3 → 4 to retrigger CI.
+
+## 2026-04-28 – Bump epoch on sweet-cursors-git to overrule AUR-built local installs
+- **Who**: Dominik, ClaudeCode
+- **Why**: `pacman -Syu` warned that local `sweet-cursors-git r445.1d92ac7-1` is "newer" than the moonarch registry's `r1.4b49c35-2`. Cause: our Gitea fork (`nevaforget/Sweet-cursors`) is a one-shot snapshot of `EliverLara/Sweet`'s `kde/cursors/Sweet-cursors/` from 2025-09-28 with a single `init` commit, so `pkgver()` always evaluates to `r1`. The local r445 came from the AUR package by `Gigas002` (source: `github.com/Gigas002/Sweet#cursors`, 445 commits, actively maintained, last cursor change 2026-03-02). Without an epoch bump, vercmp would flag the registry as a downgrade on every system that ever installed via paru/AUR.
+- **Tradeoffs**: Switching the PKGBUILD source to `Gigas002/Sweet#cursors` would track upstream and avoid the version mismatch entirely, but requires `inkscape` + `xorg-xcursorgen` makedeps and a non-trivial SVG-compile build step in CI. Cursor changes upstream are minimal in practice (one fix in 6 months), so the maintenance value is low. Keeping the snapshot keeps the build trivial and the source tiny — at the cost of being permanently frozen at the September 2025 state. Documented in the fork's README.
+- **How**: `epoch=1` added to `sweet-cursors-git/PKGBUILD`, `pkgrel` bumped 2 → 3 to retrigger CI. Added `README.md` to the `nevaforget/Sweet-cursors` Gitea repo explaining the snapshot rationale and pointing to `Gigas002/Sweet` for users who want a maintained variant.
+
 ## 2026-04-23 – Rust PKGBUILDs honour CARGO_TARGET_DIR
 - **Who**: Dominik, ClaudeCode
 - **Why**: The act_runner container sets `CARGO_TARGET_DIR=/cache/target` (for cross-build cache persistence), but `moongreet-git`/`moonlock-git`/`moonset-git` `package()` hardcoded `target/release/<bin>`. Run 87 compiled for 8 min and then failed at `install: cannot stat 'target/release/moongreet'` because the binary actually lived in `/cache/target/release/`. Silent until today because earlier builds pre-date the env var.