Install apps and trust lifecycle events

A merchant authorizes a published app through `/v1/app-store/apps/:id/oauth/authorize`. The gateway verifies store ownership, requested scopes, redirect URI, and PKCE S256 challenge before upserting an active installation.

• Grant type is `authorization_code`.
• Authorization codes are short lived and expire after 15 minutes.
• The app must keep the original `code_verifier`; token exchange rejects missing or mismatched PKCE proof.
• The response includes `redirect_to`, `code`, `state`, granted scopes, app id, installation id, and store id.

`POST /v1/app-store/oauth/token` exchanges the authorization code for a scoped app access token after checking client id, redirect URI, PKCE verifier, active installation, and one-time code redemption. The same endpoint supports `grant_type=refresh_token` and rotates the stored refresh-token hash.

• Authorization-code and refresh-token responses include `access_token`, `refresh_token`, `token_type`, `expires_at`, `refresh_expires_at`, `scope`, and `scopes`.
• Auth-core signs app access tokens as JWTs with normalized scopes.
• The installation config stores token hashes, not raw returned access or refresh tokens.

`POST /v1/app-store/oauth/token-exchange` exchanges an authenticated merchant session for an embedded app token tied to an installation and store.

• Requires protected merchant auth middleware.
• Validates active installation and store ownership.
• Used by embedded app surfaces and the app bridge fetch contract.