Api migration support UUIDs

[ming-chu]

No description provided.

[Copilot]

Pull Request Overview

This PR migrates the API to support UUIDs instead of integer IDs for service requests and related entities. The changes enable the SDK to work with UUID-based identifiers while maintaining backward compatibility through nullable fields.

Key Changes:

• Updated method signatures to accept String UUIDs instead of int IDs for service request operations
• Added UUID fields to data models (Account, AccessOfferDetails, CallSession, SessionFeedback) to support new API format
• Modified SessionFeedback to accept both legacy serviceId and new serviceUuid with fallback logic

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
pubspec.yaml	Version bump from 3.3.6 to 3.3.7
lib/src/platform_client.dart	Updated method parameters from int IDs to String UUIDs for service request operations
lib/src/models/callHistory/call_history.dart	Added UUID support to SessionFeedback and CallSession with backward compatibility
lib/src/models/account.dart	Added required uuid field to Account model
lib/src/models/access_offer.dart	Added UUID fields to AccessOfferDetails and AccountDetails models
CHANGELOG.md	Documented the UUID migration changes

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Inconsistent capitalization in documentation comments. Line 59 starts with 'Please' (capitalized) while line 62 starts with 'please' (lowercase). Additionally, both comments should say 'does not exist' instead of 'not exist' for proper grammar.

Suggested change

	/// Please check the [serviceUuid] if [serviceId] not exist.
	int? serviceId;
	/// please check the [serviceId] if [serviceUuid] not exist.
	/// Please check the [serviceUuid] if [serviceId] does not exist.
	int? serviceId;
	/// Please check the [serviceId] if [serviceUuid] does not exist.

[Copilot]

Constructor parameters serviceId and serviceUuid are marked as required, but the corresponding fields are nullable (int? and String?). This creates a breaking change and forces callers to provide values that could be null. Consider making these optional parameters to match the nullable field declarations.

Suggested change

	required this.serviceId,
	required this.serviceUuid,
	this.serviceId,
	this.serviceUuid,

[Copilot]

The uuid field is marked as non-nullable and required in AccessOfferDetails, but existing API responses may not include this field. This could cause deserialization failures. Consider making this field nullable (String?) to handle cases where the UUID is not yet available.