flatpak: take cairomm from upstream git, not the unreachable cairographics.org

[Ryanmello07]

cairomm is the only module in the Flatpak manifest whose source cannot be reached from GitHub's runners, and it took the Flatpak build test down on every run:

Failed to download sources: module cairomm: Failed to connect to
www.cairographics.org port 443 after 60000 ms: Timeout was reached

Four attempts across three runs, all identical. The host is not down — it answers a home connection in about 8 seconds — it just does not answer Azure-hosted runners, which is ordinary for a single unmirrored academic server. A retry cannot absorb that, and one was already tried.

There is no mirror

cairomm 1.16+ is released by cairographics.org and nowhere else:

source	has 1.18.0?
download.gnome.org	no — stops at the 1.12/1.15 API series
Debian pool	no — stops at 1.14.6
Gentoo distfiles	404
Fedora lookaside	404
GitLab release assets	only links back to cairographics.org

So mirror-urls has nothing to point at. The remaining source is cairo's own upstream git, which answers in ~1.5s and is where that tarball is cut from anyway.

Two changes

The source becomes type: git, pinned to the commit rather than only the tag. tag: alone would follow a tag if it moved; the commit is what keeps the build reproducible, and it is the same guarantee the sha256 gave on the archive. e0bad547705348657d09db4c9375833d8890cf54 is what 1.18.0 peels to.

-Dmaintainer-mode=false is added, because a checkout is not a released tree, so cairomm switches maintainer mode on and hard-requires mm-common-get, which the GNOME SDK does not ship:

../meson.build:151:18: ERROR: Program 'mm-common-get' not found or not executable

This is safe here, not merely expedient. mm-common-get fetches the gmmproc scaffolding that generates .h/.cc from .hg/.ccg inputs — and cairomm's 1.18.0 tree contains zero .hg and zero .ccg files. Its sources are hand-written, unlike glibmm and gtkmm which genuinely are generated. Reading meson.build:145-155, the only other thing maintainer mode provides is the documentation toolchain, and -Dbuild-documentation=false already declines that.

Honest about the trade

A release tarball is the better input, because it is what upstream tested, and a git checkout is not. The manifest comment says so and says to go back to an archive source if cairographics.org ever gets a mirror. This is the available fix, not the ideal one.

Verified

Built end to end on a GitHub runner via urnetwork/build's linux-build.yml, pointed at this branch with linux_ref:

urnetwork-flatpak-amd64   13,084,849 bytes

Against 13,082,472 bytes from the last successful tarball build — the same artifact, as expected. All seven modules built, and the run went green end to end.