fix(ci): stop leaving stale versions behind in the AUR .SRCINFO

[MotherSphere]

The AUR bump mirrors PKGBUILD metadata into .SRCINFO field by field, with one
sed per line that embeds $pkgver. That only holds while every new source gets
a sed of its own, and the icon source never did: it is matched by neither
colony-[0-9.]*::https (the filename is colony-icon-..., no digit follows
the dash) nor download/v[0-9.]*/colony-linux.

So colony-bin has been published since 0.9.0 announcing pkgver = 0.9.1 while
the icon source still pointed at the v0.8.0 tag. Nothing failed. Builds come
from the PKGBUILD, so the package was fine; only the metadata the AUR serves
disagreed with the file next to it.

Rewriting every occurrence of the outgoing version instead of naming the lines
it may appear on fixes today's case, but the durable part is the check after
it: if any mention of the old version survives, the release now fails and says
which line. The next field somebody forgets stops being invisible.

Verified by replaying the 0.8.0 -> 0.9.1 bump that produced the defect: the
result is byte-identical to makepkg --printsrcinfo on the 0.9.1 PKGBUILD,
apart from the binary checksum, which the workflow takes from the downloaded
artifact rather than from the previous .SRCINFO.

Generating .SRCINFO with makepkg would remove the whole class of bug, but the
runner is Ubuntu and it would mean a container in the release path: an
unverifiable step whose failure costs every future version bump, traded
against metadata that is merely cosmetically stale. Not worth it here.