Get App

AppSchema plus the connected integration rows themselves, for the six handlers that return an app as the top-level response.

Flask's AppSchema nests both shapes (schemas.py:906-919) and the dashboard reads both: the integrations list inherited above is the vw_service_hooks summary, and these are the rows, carrying everything rendered from an integration's own columns -- selected channel/board/project, credentials, layout, two-way-sync flags. fastapp shipped only the list (2026-09-09 ruling); reversed by developer decision 2026-09-21 because that left the dashboard without those fields.

A SUBCLASS, not eleven more fields on AppSchema, and that is load-bearing. AppSchema is also nested at BaseIssueSchema.app and twice in crash_reporting/schemas/crash.py, and an optional field with a default does NOT make an unloaded relationship safe there: Pydantic reaches it by getattr, which raises MissingGreenlet rather than AttributeError, so the default is never reached -- the same gotcha AppSchema.integrations already documents, and verified here by putting these on AppSchema first and watching every crash-REST and issue-detail test fail. Keeping them on a subclass means those paths neither pay for eleven extra selects nor carry integration objects Flask does not put on an issue or crash payload at all.

youtrack is absent, not null: no fastapp model exists (permanently out of migration scope) and the key would advertise support that does not exist. sentry is absent because Sentry is team-scoped -- Flask's AppSchema omits it too.