Fix: Add cookiePath config option for multi-shop non-embedded apps

[byrichardpowell]

WHY are these changes introduced?

Fixes #451
Related: Shopify/shopify-app-template-react-router#156

Non-embedded apps that support multiple shops simultaneously in separate browser tabs hit a cookie collision: all shops share a single shopify_app_session cookie scoped to path=/, so each OAuth callback silently overwrites the previous shop's session. The user in Tab A then unknowingly operates on Tab B's shop after Tab B completes auth.

This is a known limitation acknowledged by paulomarg in issue #451 (Sept 2023) and has since resurfaced in the React Router template repo.

WHAT is this pull request doing?

Adds an optional cookiePath config option to ConfigParams (in @shopify/shopify-api) that controls the path attribute written on the shopify_app_session cookie during OAuth callback.

Before: hardcoded path: '/' — domain-wide, one cookie shared across all shops.

After: configurable via a static string or a per-session factory function:

// Default — unchanged behaviour
shopifyApi({ cookiePath: '/' })

// Multi-shop apps: scope cookie to a shop-specific URL prefix
shopifyApi({
  cookiePath: (session) => `/shops/${session.shop}/`,
})

When each shop is served under a distinct URL prefix, the browser maintains one cookie per shop and delivers only the matching cookie per request — no collision.

Changes:

• lib/base-types.ts — adds cookiePath?: string | ((session: Session) => string) to ConfigParams with full JSDoc
• lib/auth/oauth/oauth.ts — resolves the configured path at callback time and passes it to setAndSign
• Tests — three new test cases: default path /, static string path, factory function path
• Changeset — minor bump for @shopify/shopify-api

Note: this fix requires apps to structure their routing with shop-scoped URL prefixes. The library cannot derive the path automatically (see investigation notes on the chicken-and-egg read-time problem). The JSDoc explains this requirement.

Type of change

• Patch: Bug (non-breaking change which fixes an issue)
• Minor: New feature (non-breaking change which adds functionality)
• Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have used pnpm changeset to create a draft changelog entry (do NOT update the CHANGELOG.md files manually)
• I have added/updated tests for this change
• I have documented new APIs/updated the documentation for modified APIs (for public APIs)