OpenMetrics: add a shipped label to the app inventory metric, and expose setup checks

The OpenMetrics endpoint added in 33 already covers a lot, and it makes something practical
that wasn't before: reading an instance's state from outside, without shell access on it. Two
small additions would carry that further.

For context, I maintain an open-source monitoring dashboard for Nextcloud instances, which is
where both of these come from.

1. A shipped flag on the app inventory

Today:

# 33.0.6
nextcloud_apps_info{activity="6.0.0",dav="1.36.0",…} 1
# 34.0.1
nextcloud_app_enabled{app_id="activity",version="7.0.0"} 1

Knowing whether an app ships with the server would make this inventory directly comparable with
the app store. Bundled apps have frozen store entries and versions that track the release, so
today they all read as outdated in such a comparison; with the flag, the metric alone is enough
to tell which third-party apps are genuinely behind.

nextcloud_app_enabled{app_id="activity",version="7.0.0",shipped="1"} 1

IAppManager::isShipped() already has it, and it's one label on a metric that's already emitted.

2. Setup check results

occ setupchecks and Settings → Overview already compute a full health picture. Exposing it as
metrics would allow tracking it over time and alerting on regressions, which the CLI form
doesn't lend itself to.

nextcloud_setupcheck{check="DatabaseHasMissingIndices",category="database"} 2

Descriptions and documentation links wouldn't survive the metric model, but the per-check status
is the actionable part.

Context: I first raised the setup checks part in nextcloud/serverinfo#960, which was closed with
a pointer to OpenMetrics, on the grounds that serverinfo shouldn't depend on other apps. That
makes sense and since neither of these is app-specific, nextcloud/server seemed the right
place for them.

Happy to split this into two issues if that's easier to track.

One question that stayed open on #960: is serverinfo expected to keep evolving, or will
monitoring data progressively move to OpenMetrics? Knowing which surface to build against
would help.

Start at the existing OpenMetrics endpoint and the app inventory metric, then inspect IAppManager::isShipped() to understand the shipped value. Compare the setup checks produced by occ setupchecks and Settings → Overview, using serverinfo#960 for context. Done means both requested metric surfaces expose actionable values without app-specific dependencies, with appropriate tests and documentation if the project requires them.