Clarify deprecated user_id in connected-account responses

This replaces #4508, which I closed because it was filed from the wrong GitHub account. Reposting here from my personal account.

The connected-account response contract is unclear about whether applications can rely on receiving the account owner's user_id.

At next commit 0dae2623c26ec4cb2c523fb4cfa0536ced932348:

• The v3 and v3.1 list/retrieve OpenAPI schemas include user_id in the required response fields, but also mark it deprecated. Its description says the API will stop returning it and callers should filter by user identifier instead. See the v3 list schema, v3 retrieve schema, and v3.1 list schema.
• The public list reference still shows user_id in its example response.
• The TypeScript SDK's response schema omits userId, and its transformer does not map user_id.

Deprecation can reasonably precede removal, so this may be intentional. The missing piece is a clear statement of the supported behavior and migration path.

Why this matters

A project-level reconciliation job needs to distinguish untracked accounts owned by existing application users from potentially orphaned accounts. Without returned ownership, it needs a second paginated listing filtered by existing user identifiers. We want to confirm that this is the supported approach before proposing any SDK change.

Requested clarification

1. Is returning user_id still supported during deprecation? Does visibility vary by account origin or caller permissions?
2. Is the TypeScript SDK intentionally excluding this field?
3. Is listing with user_ids the recommended way to establish ownership for reconciliation?

Could the connected-accounts documentation explain this policy and align the schema/example where appropriate? Happy to contribute a documentation change once the intended behavior is confirmed.

This report is based on public source and API contracts, not live response testing. It does not assert a runtime defect or request disclosure of restricted owner identities.