Outbound Apps: add listAppsWithTenantToken — tenant-level equivalent of listAppsWithUserToken

[tarracharan-glitch]

Summary

v2.10.0 (#754) added listAppsWithUserToken(userId, tenantId?), which returns the outbound app IDs a user holds a valid token for. This replaced the previous workaround of calling fetchToken once per app and treating the E111504 not-found error as "not connected".

There is no tenant-level counterpart. For credentials stored at the tenant level — static API keys uploaded via uploadTenantApiKey, or tenant-scoped OAuth tokens — answering "which apps does this tenant hold a token for?" still requires the old pattern: one fetchTenantToken call per app, sniffing the not-found error. With many outbound apps this fans out toward management API rate limits, and connection-status checks typically sit on a hot path (rendering "connected / not connected" state in a UI).

Requested API

listAppsWithTenantToken(tenantId: string): Promise<SdkResponse<string[]>>

Returns the outbound app IDs the tenant holds a valid token for — symmetric with listAppsWithUserToken.

Expected semantics

We verified that listAppsWithUserToken already includes apps whose credential was stored via uploadUserApiKey (uploaded static keys and OAuth tokens live in the same token store):

listAppsWithUserToken(user)            → []
uploadUserApiKey(app, user, key)       → ok
listAppsWithUserToken(user)            → [app]

The tenant-level list should behave the same way: include apps with tenant credentials of either kind (OAuth tokens and keys uploaded via uploadTenantApiKey).

Note on scope

From the API reference, only list-outbound-apps-with-user-token exists at the REST level — so this appears to be an API + SDK request rather than SDK-only. Filing here since #748/#749 were routed successfully from this repo; happy to move it wherever it belongs.