Correct existing test scenarios that don't match the API definitions #235

Problem description

Several existing scenarios would fail against an implementation that follows the API definitions:

• webrtc-call-handling createSession success: the payload sends clientCorrelator, which was removed from the API (createSession.feature#L21).
• webrtc-call-handling updateSessionStatus success: PUT is sent without a body, although status is required (updateSessionStatus.feature#L11-L18).
• webrtc-events-subscriptions create success:
  • It sends registrationId in subscriptionDetail, which is not defined.
  • Its subscriptionExpireTime is in the past.
  • It validates a possible 202 response against Subscription instead of SubscriptionAsync (createNotificationChannelSubscription.feature#L20-L35).
• The "path parameter not included / set to empty → 400" scenarios for get, update and delete in all three APIs address a different path (/sessions/, /subscriptions/), so they don't reach the operation under test (e.g. getSessionDetailsById.feature#L33-L50). Some of these set a request body on a GET.
• The update scenarios tagged no_request_body / empty_request_body change the path instead of the body. Scenarios for a missing or invalid status are absent.
• webrtc-registration createRegistration success sends only deviceId, which works only with a 3-legged token. The feature doesn't state the token type, and there is no 2-legged scenario with phoneNumber.
• Success responses are validated against MediaSessionInformation instead of MediaSessionResponse.

Expected action

Correct the listed scenarios so they use valid input and reach the operation under test. Declare the token-type assumption in the feature context (API Testing Guidelines).

Additional context

Found during the review of r3.1. This is separate from #229, which covers missing error scenarios; this issue is about existing scenarios. It can be done together with #229.