feat(aep-mobile): accept decisioning.propositionFetch in personalization fetch matchers

[mohdashraf010897]

Description

Mobile SDKs are migrating the XDM eventType used to fetch propositions from the deprecated personalization.request to decisioning.propositionFetch, aligning Mobile with the XDM spec already used by Web SDK. Both SDK PRs are open:

• Optimize: aepsdk-optimize-ios#159
• Messaging: aepsdk-messaging-ios#491 — in-app messages, content cards, code-based experiences

The Assurance event matchers in @adobe/griffon-toolkit-aep-mobile were hardcoded to personalization.request only, so events from updated SDKs would silently stop matching — breaking the Optimize and IAM plugin event lists and the "Review and Simulate" view.

This PR makes the affected matchers accept both event types, so Assurance keeps working with old and new SDK builds. The change is additive — no existing session breaks.

Changes

• New src/personalizationFetchEventTypes.ts — single source of truth:
  • LEGACY_EDGE_EVENT_TYPE = 'personalization.request'
  • PROPOSITION_FETCH_EDGE_EVENT_TYPE = 'decisioning.propositionFetch'
  • edgeEventTypeMatcher — a kit.combineAny([...]) JMESPath expression matching either value
• src/optimizeMessagesRequest.ts, src/personalizationEdgeRequest.ts, src/iamMessagesRequest.ts — matcher now uses edgeEventTypeMatcher; export the two constants
• schemas/personalizationEdgeRequest.json — eventType widened from const to enum of both values. The optimize and iam schemas inherit this via allOf, so all three are covered by the single schema edit.
• src/index.ts — re-exports the new module
• package.json — 0.13.0 → 0.14.0

Why all three matchers

Both the Optimize and Messaging SDK PRs migrate to the identical decisioning.propositionFetch string, and both are already open. Because the matcher is additive (OR both), accepting the new type in the IAM matcher is safe today (IAM still emits the legacy type → still matches) and forward-ready for when #491 ships — avoiding a second publish/promote cycle and preventing the IAM plugin from silently breaking later.

Related Issue

• MOB-25095 — [Optimize][Plugin] Verify and fix Review and Simulate functionality for updated eventType
• MOB-24547 (parent) — Mobile SDKs using a deprecated event name to fetch decisions
• PLATIR-51299

Motivation and Context

Without this change, any Assurance session from an SDK that adopted decisioning.propositionFetch shows zero optimize/personalization/IAM requests — the matcher fails silently, no error. Using a shared OR-matcher (rather than flipping the constant) preserves support for the installs still on older SDKs.

How Has This Been Tested?

New test/personalizationFetchEventTypes.spec.ts — 11 assertions, all passing via repo-local jest:

• Constant values for both event types
• isMatch matches legacy and new types, and rejects unrelated decisioning.propositionDisplay — for all three matchers (optimizeMessagesRequest, personalizationEdgeRequest, iamMessagesRequest)

Existing sharedStateConfig.spec.ts still passes (no regressions). Downstream-validated in the Assurance plugins repo (x-optimize) against a linked 0.14.0 build.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• All new and existing tests passed.