Canonicalize scopes for store auth

[dmerand]

What

Canonicalize the scopes returned by shopify store auth before comparing them to the requested scopes.

This treats compressed returned scopes like write_products as satisfying read_products,write_products, while still failing auth when unrelated requested scopes are actually missing.

Why

In the PKCE flow, Shopify can return the highest-privilege scope instead of echoing every requested scope. That makes store auth reject valid responses when the request includes both read and write access for the same resource.

This PR aligns scope validation with that behavior so store auth only fails when a real requested scope is missing.

How

• expand implied write_* -> read_* scopes when validating the token response
• use the same scope-compression approach as the existing AuthScopes implementation in shopify-api-js
• keep storing the raw scopes returned by Shopify
• document that stored session scopes are raw, not an expanded effective set
• add focused coverage for:
  • compressed write scopes satisfying requested read+write scopes
  • unrelated missing scopes still failing auth

Testing

To test manually:

1. Run shopify store auth --store <store> --scopes read_products,write_products
2. Complete the PKCE flow
3. Confirm auth succeeds when Shopify returns write_products

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[dmerand]

• Store auth/execute UX improvements #7151
• Adjust store auth warning for non-canonical store domain #7150
• Canonicalize scopes for store auth #7149 👈 (View in Graphite)
• Fix store auth API Client key #7148
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[ryancbahan]

maybe worth adding a code comment for context on why we need this