Offer the first app for the workspace picked on the server picker - #1449

What and why

Two problems seen in an end-to-end test on Cloud after #1440 and #1441.

1. Post-approve page after "Choose what to connect"

A user in several workspaces gets the "Choose what to connect" picker. If they picked an empty workspace where they are ADMIN or EDITOR, they went straight back to the client and never saw the first-connector page. There were two reasons:

• POST /auth/select-servers always redirected to /callback. Only the no-picker path called maybeOfferFirstConnector.
• maybeOfferFirstConnector counted connectors and checked the role in users.organizationId (the primary workspace), not in the workspace granted to this client.

Changes in packages/backend/src/auth/login.controller.ts:

• New grantedWorkspace(clientId, userId, fallback). It resolves the one workspace this connection reaches, the same way the shared endpoint does:
  • an organization grant gives that organization;
  • a servers grant gives the servers' organization when they are all in one workspace;
  • no grant (connections from before grants existed) gives users.organizationId;
  • none, or servers spread over several workspaces, gives null. With no single workspace, nothing is offered.
• maybeOfferFirstConnector uses that workspace for the connector count, the role check, the trial lookup and the product event.
• handleServerSelection calls maybeOfferFirstConnector after a valid selection. It falls back to the old redirect when there is nothing to offer. The CSRF check and the signed pending_grant identity check stay in front of it, unchanged.
• The social provider used to sign in (continueWith= dashboard links) is kept across the picker. It travels in a signed, httpOnly pending_grant_social cookie and is checked against the enabled providers when read.
• POST /auth/first-app resolves the org through the same helper, so the app is installed into the workspace the page was offered for. The connector still lands on the granted servers of that workspace. Its CSRF cookie check, the signed login_user check, the pending-authorization check and the role/plan checks (canSetUp) are unchanged. One behaviour change: a grant whose servers span two workspaces now answers 403 ("page expired") instead of installing into the first server's workspace. The page is never offered for such a grant.

Single-workspace behaviour does not change. The picker is not shown there, the silent grant points at the user's own workspace, and the helper resolves to that workspace as before.

Cloud / self-hosted: the first-connector page and /auth/first-app stay Cloud-only (isCloud() guards, unchanged). On self-hosted, the picker submission still redirects straight to /callback. A spec covers this.

2. Etsy "app pending" panel

Etsy returns the same 403 for an app that is still Pending and for an active app with a wrong shared secret. The panel's headline said " has not approved your app yet", which is wrong in the second case. The headline is now neutral and the body covers both cases:

• en: " does not accept these keys yet." / "If your app is new, reviews it, usually within a few days: we'll e-mail you when it's approved, nothing else to do. If your app is already active, copy the shared secret again from your app page. Your keys are saved."
• de and it: translated to match.

The backend appPending flag and the Etsy verifyHints["403"] already name both cases, so no logic changes. Only the comments on checkAppKeys and on the appPending type in api.ts now say the flag means "maybe pending". The Playwright test in connector-guided-setup.spec.ts asserts the new text.

Not changed: the guided setup's "Wait for Etsy's approval" step (connectorGuide, "Etsy has not approved your app yet"). It already has its own "Already approved, but this still waits" path back to the keys.

Cloud cherry-pick note: the Cloud branch has no i18n, and its page.tsx still has the old English strings inline. A cherry-pick of this PR there must put the new English title and body inline in packages/frontend/src/app/connectors/setup/[slug]/page.tsx instead of the message files.

Tests

New specs in packages/backend/src/auth/login.controller.spec.ts:

• Multi-workspace user picks an empty workspace (whole workspace, or servers in it): the first-connector page is shown for that workspace, and the event is recorded with that organizationId.
• Picks a workspace that has connectors, or one where they are VIEWER, or servers in two workspaces: straight to /callback.
• Self-hosted: straight to /callback.
• Sign-in path: the granted workspace is counted, not the primary one.
• The social provider is carried across the picker. An unknown provider in the cookie is ignored.
• first-app installs into the granted workspace, not the primary one. It falls back to the user's own workspace when there is no grant. It refuses a none grant and a grant spanning two workspaces.

Commands run

No ee/ change.