Fix default IdP validation rejecting server-wide identity providers

[jaisinha77777]

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Fixes #3290

What

Setting a default identity provider (Platform SSO) on a resource's Authentication tab fails with Identity provider not found in this organization on Community Edition / self-host since 1.19. As noted in the issue thread, hitting Save Settings on any Auth tab that has a default IdP set reproduces it.

Why

setResourcePolicyAccessControl validates skipToIdpId with an inner join on idpOrg, so it only accepts IdPs that have an org link row. But server-wide IdPs created through the server admin panel (createOidcIdp) never get an idpOrg row - only org-scoped IdPs do (SaaS build or identity_provider_mode: org). The check shipped with the resource policies rework in 1.19, which is why this appeared after upgrading from 1.18.

The resource login page itself has the correct rule: it offers org-scoped IdPs when build === "saas" || identityProviderMode === "org", and otherwise offers every server-wide IdP from /idp. So any server-wide IdP is genuinely usable as a skip-to IdP on self-host - the save-time validation was just stricter than the runtime behavior.

How

• Added canOrgUseIdp(idpId, orgId) in server/lib/idp/canOrgUseIdp.ts: left-joins the org link and only requires it when IdPs are org-scoped (SaaS build or IDENTITY_PROVIDER_MODE === "org", matching how other OSS routes read the mode). Otherwise any existing IdP passes.
• Used it in setResourcePolicyAccessControl (OSS) and createResourcePolicy (private), which had the same inner-join check duplicated.

Behavior is unchanged for SaaS / org-scoped mode: the org link is still required there.

Testing

• tsc --noEmit passes on both the oss and enterprise configurations.
• Traced both affected routes plus the login page IdP resolution to confirm the validation now matches what the auth flow accepts at runtime.