feat: add strictImpersonationPermissions setting for checkUserPermission

[wender]

What problem is this solving?

In version 3.5.1, checkUserPermission started scoping permissions to the impersonated profile unconditionally. That prevents the acting user's permissions from reaching the storefront during impersonation, but it also removes permissions that the default B2B Suite configuration relies on:

• can-checkout is granted to store-admin, sales-admin, sales-manager, sales-representative, customer-admin and customer-approver, but not to customer-buyer.
• Aggregation is therefore what allows a sales representative impersonating an Organization Buyer to complete a purchase, a capability described for sales roles in docs/README.md.
• With strict scoping always on, that checkout stops working.

Both behaviors are legitimate depending on the store: some need the storefront to render exactly what the impersonated user can do, others depend on the acting user's rights during impersonation (for example approval flows).

This also affects both impersonation flows, not only vtex.telemarketing. The B2B Organizations app switches the profile namespace through storefront-permissions.storeUserId, which vtex.profile-session takes as an input, so authentication.storeUserEmail and profile.email diverge in both flows.

What changed

The behavior is now controlled by a new app setting:

strictImpersonationPermissions	Result during impersonation
true	Only the impersonated profile's permissions and role (the 3.5.1 behavior).
false (default)	Deduplicated union of the acting user's and the impersonated profile's permissions; role prefers the acting user's, falling back to the impersonated profile's (the 3.5.0 behavior).

Sessions outside impersonation are unchanged in both modes.

This restores the 3.5.0 default on purpose. Apps auto-update within a major, so keeping strict scoping on by default would continue to remove can-checkout in stores that did not opt into the change. Stores that want strict scoping enable the setting. Flipping the default to strict is a candidate for the next major, with a migration note.

Notes for reviewers:

• The aggregated branch reproduces the pre-3.5.1 semantics exactly, including the role fallback order.
• App settings are read only for impersonation sessions, through the existing 5-minute LRU cache (getCachedAppSettings), so regular sessions are not affected. A settings read failure logs a warning and falls back to the default (aggregated) mode.
• UserPermissions { role, permissions } is unchanged, so there is no GraphQL schema change.
• Documents the query's behavior during impersonation in docs/README.md, which was previously unspecified.

How should this be manually tested?

With the setting disabled (default):

1. As a sales-representative, impersonate a customer-buyer through the B2B Organizations app.
2. Confirm checkUserPermission returns the union of both sets, that can-checkout is present, and that checkout completes.

With strictImpersonationPermissions enabled in the app settings:

3. Repeat the impersonation and confirm checkUserPermission returns only the buyer's role and permissions, with no permission coming from the sales representative.
4. Repeat the check for a vtex.telemarketing session impersonating a customer.
5. In both modes, confirm that a regular (non-impersonated) login is unaffected.

Screenshots or example usage:

N/A (backend resolver and app setting)

Ref: B2BTEAM-3566

[vtex-io-ci-cd]

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

• Patch (backwards-compatible bug fixes)

• Minor (backwards-compatible functionality)

• Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

• No thanks, I would rather do it manually 😞