[Flathub] Gate CI on the repo linter mode

[TheZupZup]

Follow-up to #449 (PR #614). Blocked on #437.

Corrected. The first version of this issue claimed the appstream mode reported metainfo-missing-screenshots and therefore had to wait alongside repo. That was wrong, and Codex caught it on #614. Both findings come from repo; appstream is clean and now gates CI. Only repo is deferred.

What is missing

scripts/flathub_builder_lint.py drives all three of flatpak-builder-lint's modes. CI now gates on two:

Mode	Gates CI	Result today
manifest	yes, before the build	clean
appstream	yes, after the build	clean
repo	no	metainfo-missing-screenshots, appstream-screenshots-not-mirrored-in-ostree

appstream and repo are different checks despite both mentioning screenshots: appstream reads the catalogue appstreamcli compose generated, repo reads the exported OSTree Flathub would publish. Only the second reports anything.

Why repo is not wired up yet

Not because the tooling is unfinished. Because it reports real submission blockers whose fix is to take screenshots (#437), not to change anything in the linting.

Wiring it in before the screenshots exist leaves two options, and both are worse than waiting:

• A permanently red job. It trains everyone to ignore the check, and buries any genuinely new finding underneath the one everybody already knows about.
• An exception. flatpak/flathub-lint-exceptions.json is for a finding a person judged wrong or unavoidable for Linthra. A finding that is simply not fixed yet belongs in its issue. [Flathub] Submit Linthra to Flathub #456 also requires that file to be empty at submission, so an entry would have to come straight back out.

What to do

1. Land [Flatpak] Add Flathub-quality screenshots #437 (screenshots, per docs/flathub-screenshots.md) and the <screenshots> block in the metainfo.

2. Confirm the mode is clean:

   python3 scripts/flathub_builder_lint.py --repo flatpak/repo-ci

3. Add --repo flatpak/repo-ci to the existing "Lint the AppStream catalogue" step in .github/workflows/flatpak-build.yml, and rename the step to cover both.

   It already sits after "Install and launch packaged Flatpak", which is deliberate and should stay: a failed step ends the job, so a lint ahead of the launch smoke stops the package being installed and launched at all. There is a guardrail asserting that order.

4. Delete the the repo mode waits for the screenshots that let it pass guardrail in test/tooling/flathub_metadata_guardrails_test.dart.

5. Update the "What CI gates on today" table in docs/flathub-builder-lint.md.

Acceptance criteria

• CI gates on all three linter modes.
• The launch smoke still runs before the lint, asserted by a test.
• flatpak/flathub-lint-exceptions.json is still empty.
• docs/flathub-builder-lint.md no longer describes any mode as deferred.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QLDN6yzLpSdXoFHYJNqyyp