[Improve] Add enabled integrations summary to daily instance report

[roomote-roomote]

​Created by Roomote. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

The daily anonymous instance report now includes an integrations summary alongside the existing automations summary. It reports a flat { enabled, enabledNames } payload where enabled is the total enabled integration count and enabledNames one list of enabled integration names: built-in MCP integrations keep their safe catalog ids, while each enabled custom MCP or personal server appears as a deterministic custom-integration-N stub and each live API-key (service credential) integration as api-key-integration-N, numbered from sorted underlying ids. Enabled MCP ids come from an extracted helper that keeps deployment connections while dropping user-scoped connections of soft-deleted users; custom integrations come from the enabled custom/personal server rows via a second helper, so servers using none, static_headers, or stdio are counted too, and personal servers of soft-deleted owners are excluded like the runtime lookup does. API-key integrations reuse the canonical live grant predicate. custom:<id> connection entries are skipped so OAuth-based custom servers are never double-counted. Labels and origins never leave the instance.

Why this change was made

The report already covered enabled automations but not enabled integrations. Integration names are owner-authored and may be sensitive, so custom and API-key entries must be anonymized before they reach the Ping service or PostHog, while built-in catalog names are safe to emit.

Impact

The anonymous daily ping gains an integrations field with an accurate enabled total and enabled names without ever leaking user-authored integration labels, origins, or any other customer data, and it stays accurate for non-OAuth custom servers as well as for items whose owners were soft-deleted.

Validation

Targeted test file passes 20/20 including regression coverage for each review fix; root lint and full workspace typecheck pass; pre-push hooks green. The one full-suite failure observed locally is a preexisting shared-database seed-demo-data.test.ts flake that passes standalone and is untouched by this diff.

[roomote-community]

No code issues found. See task

• Enabled non-OAuth custom MCP servers are omitted from the integrations summary (packages/db/src/lib/instance-report.ts:927).
• Credentials owned by soft-deleted users are counted as active (packages/db/src/lib/instance-report.ts:937).
• Personal MCP servers owned by soft-deleted users are still counted as enabled (packages/db/src/lib/instance-report.ts:959).
• The personal-server regression test relies on a global aggregate while the suite shares a database, so concurrent integration fixtures can make the delta and indexed stub assertion flaky (packages/db/src/lib/__tests__/instance-report.test.ts:358).
• Enabled MCP connection rows of soft-deleted users are included in the integration summary (packages/db/src/lib/instance-report.ts:1050).

_{Reviewed 03ec8f}

[roomote-roomote]

All outstanding review findings are fixed; the MCP connection ownership one landed in commit 03ec8fd2:

• Custom integrations come from the enabled custom_mcp_servers and personal_mcp_servers rows via collectEnabledCustomIntegrationIds(); custom:<id> connection entries are skipped to avoid double-counting.
• The API-key integration count reuses liveServiceCredentialWhere().
• Enabled personal MCP servers owned by soft-deleted users are excluded via an owner join with users.deletedAt IS NULL.
• The personal-server regression test asserts id membership directly rather than global aggregate deltas.
• Enabled MCP ids now come from the extracted collectEnabledMcpIds() helper, which keeps deployment connections (userId IS NULL) while filtering user-scoped connections of soft-deleted users; a dedicated test covers live-owner, deleted-owner, deployment-scoped, and disabled rows.

Validation: the instance-report test file passes 20/20, format, lint, check-types:fast (27 packages), and pre-push hooks are green. All review threads are resolved; the PR body reflects the shipped result.