Packaging: stable package specs still hard-Require dgop after it was dropped as an external dependency

### Summary

Commit `da664565b1e17ddf9ec763581bb940fbd80861b4` ("dgop: drop dgop as an external dependency and use dgop/gops internally", fixes #3033) removed `dgop` as an external runtime dependency. It updated the Go installer, the `dms doctor` optional-dependency check, and **all five `-git` package variants** — but the **five stable package variants were left declaring `dgop` as a hard runtime dependency**.

So for the same application, `dms` and `dms-git` now disagree about their dependencies.

### Evidence — stable variants still declare dgop

| File | Line | Declaration |
| --- | --- | --- |
| `distro/debian/dms/debian/control` | 18 | `dgop,` |
| `distro/fedora/dms.spec` | 24 | `Requires: dgop` |
| `distro/opensuse/dms.spec` | 22 | `Requires: dgop` |
| `distro/ubuntu/dms/debian/control` | 18 | `dgop,` |
| `distro/void/srcpkgs/dms/template` | 28 | `depends="quickshell accountsservice dgop matugen dbus elogind mesa-dri"` |

### Evidence — the corresponding -git variants were cleaned

`grep -n dgop` over `distro/debian/dms-git/debian/control`, `distro/fedora/dms-git.spec`, `distro/opensuse/dms-git.spec`, `distro/ubuntu/dms-git/debian/control` and `distro/void/srcpkgs/dms-git/template` returns nothing at `af866ba6`.

### Why dgop should not be a hard dependency

`dgop` is now an optional integration, not a runtime requirement:

- `core/go.mod:6` links `github.com/AvengeMedia/dgop` as an in-process Go library — the monitoring widgets no longer shell out to an external binary.
- `core/internal/matugen/matugen.go:77` lists it as `{ID: "dgop", Commands: []string{"dgop"}, ConfigFile: "dgop.toml"}` — that entry is command-gated, so the `dgop.toml` matugen template only runs when a `dgop` binary happens to be present. Its absence degrades to "this optional theming target is skipped", not an error.
- `core/cmd/dms/commands_doctor.go` dropped its `dgop` entry in the same commit.

### Impact

- Stable-package users on Debian, Ubuntu, Fedora, openSUSE and Void get an external `dgop` CLI pulled in that the shell no longer requires.
- On Void, `dms` and `dms-git` declare `conflicts="dms"` on each other, so the two variants of the same app now produce materially different installs.
- `run-copr.yml` and `run-obs.yml` only rewrite `Version`/`*_PLACEHOLDER` fields — neither touches `Requires` — so the stale declaration ships to Fedora COPR and openSUSE OBS users as-is.

### Also stale (docs)

`distro/void/README.md` still presents dgop as mandatory, at lines 8, 59, 81, 82 and 90 ("Installing `dms` automatically pulls in ... `dgop` ...", "dms requires dgop").

### Related

#3382 reports the same underlying request for the XBPS template ("dgop needs to be removed as dependancy"). Its other point — that the template "is still on 1.5.0" — is expected: that string is a placeholder CI overwrites (`distro/void/srcpkgs/dms/template` line 8 documents this, and `.github/workflows/run-xbps.yml:223-224` rewrites `version=`/`checksum=` from the release tag), so no change is needed there.

### Suggested fix

Drop `dgop` from the five stable specs to match their `-git` counterparts, and refresh the Void README dependency list. If the intent is instead to keep it, then the `-git` variants are the inconsistent side — but the commit message, the doctor change and matugen's command-gating all point to dropping it.

---

*Filed by an automated audit worker: I read the repository at `af866ba6616eda0309ef9a20f14b846e3464e28a` and verified each claim above by direct inspection. I have no ability to build or install the distro packages in my environment, so the package-level impact is reasoned from the spec files rather than observed on a running install.*

Start with the five stable package files listed in the issue, then compare each with its corresponding -git variant. Update the stable dependency declarations and review distro/void/README.md for the stale dgop requirements; done means no stable package spec or README presents dgop as a mandatory dependency.

Written by the indexing model from the issue text.